Some privacy email providers, including Autistici, Disroot, Dismail, Vivaldi, have DMARC policy setup to “reject”. As you see follows.

_dmarc.autistici.org.	2998	IN	TXT	"v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]"

_dmarc.disroot.org.	3143	IN	TXT	"v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected];"

_dmarc.dismail.de.	14400	IN	TXT	"v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:[email protected]"

_dmarc.vivaldi.net.	300	IN	TXT	"v=DMARC1; p=reject; rua=mailto:[email protected]"

They all have “p=reject” in their DMARC records.

I was thinking this setting is not good for a mailing list user. For instance, when you use one of the addresses to subscribe to mailing lists, you will have the delivery issues.

This is because, mailing list service generally rewrites the sender address (SRS) to the list address, thus SPF verification will have no help to DMARC authentication of your domain. And most list servers add signatures at the footer of messages. Then DKIM will fail for the original message sent from your server.

Since both SPF and DKIM have no help to your sender domain, DMARC validation fails, the message will be rejected by other MTAs following the DMARC setting above.

So I was thinking it’s better not set up a “p=reject” in DMARC for those providers. They are privacy oriented providers, use open source mostly. Many tech people are using the services above. As a comparison, Riseup has the better setting as the following.

_dmarc.riseup.net.	600	IN	TXT	"v=DMARC1;p=none;adkim=r;aspf=r;rua=mailto:[email protected]"

As you see above, their policy is “p=none” which is good for mailing lists delivery.

In the hostloc forum, we conduct a usage vote on the most commonly used international email addresses. As of now, a total of 313 users have participated in voting.

Among them, gmail is far ahead, with a user rate of 56%. Outlook mail is second, with a user ratio of 24%. Adding the two together, the cumulative ratio reaches 80%. Surprisingly, the third place is Yandex mail, with a user share of 7%. This may be because it is in the Chinese market.

The last two are Yahoo and GMX, and the user ratio is negligible. GMX is a European mail provider, which is understandable. But as an absolutely established service, Yahoo has been reduced to the point where no one uses it, which is a pity. In the same way, this vote only represents the Chinese market.

Today you can get a free domain email easily. You need 3 steps as follows.

• Get a free domain name. nic.eu.org does provide reliable domains for free.
• Get a free MX server for receiving email. I suggest you use Cloudflare as email forwarder.
• Get a free smtp server for sending email. My solution is to use Riseup‘s free smtp server.

Given that you have got a free domain at nic.eu.org, say it’s demo.eu.org.

You can host the domain’s DNS to cloudflare, where you will get free email forwarding as well. Cloudflare’s email forwarding calls Email Routing, which has the doc here.

After you have set Email Routing, you need to update SPF record in Cloudflare DNS. The SPF must have Riseup’s IP addresses included. The new SPF looks as the following.

demo.eu.org.	300	IN	TXT	"v=spf1 include:_spf.mx.cloudflare.net include:_spf.riseup.net ~all"

I assume you have got an email account at Riseup. Now you will forward the domain email address to your Riseup email account. That’s to say, [email protected] will be forwarded to [email protected].

Since riseup can create separated senders (i.e, your domain user) as aliases, you can just set up [email protected] in their control panel as the sender. This sender can be added into their webmail.

As you see above, I have created [email protected] as the alias in Riseup’s control panel.

Go to Riseup webmail (Roundcube), add [email protected] as the sender identity. Now you can either receive email in their mailbox (though it’s forwarded by Cloudflare), or send email from their webmail.

Until now, you have created a customized domain email for free following the steps above. If you have found any issues during the operations, you can ask me by email.

port 25 is for smtp communication between MTAs. It should not have SASL auth enabled on this port. In postfix, we have to changes two files to implement this.

The first, in main.cf, comment out this line:

smtpd_sasl_auth_enable = yes

Just comment it out, the default value for this option is “no”.

The second, in master.cf, updates these two lines:

submission inet n       -       y       -       -       smtpd
  -o smtpd_sasl_auth_enable=yes

smtps     inet  n       -       y       -       -       smtpd
  -o smtpd_sasl_auth_enable=yes

The first line “submission” is for port 587. The second line “smtps” is for port 465. If you were not using port 465 (SMTPs), then the second line can be ignored.

Now restart postfix and it should work.