It's great to have the two-liner, but can someone explain what these settings actually mean?

Edit: Also, if I have a domain that currently does not send email but may in the future, am I hurting my future self by setting any of these?

Sure!

First off, no you are not hurting yourself. If anything, you're helping because you're making it harder for your domain to be flagged by spam filters for things you haven't done.

Here's a quick explanation of SPF, DKIM and DMARC.

SPF

- It's a simple record in your DNS that let's you list IP addresses authorized to send email from your domain. 3rd party senders will often ask you to include them in your spf record. With nothing in the record and the "-all" meaning strictly enforced, you've not authorized any senders at all with SPF.

DKIM

- DKIM has to be setup for every sending mail server with a configuration mapped to a key located in your DNS config. If a receiving mail server gets a message without a DKIM signature, it has no way of knowing it should be there.

DMARC

- When you enforce a dmarc policy, you tell a server that receives email saying it is from your domain to only accept it if the message passes either an SPF or DKIM check that "aligns" with the domain. It's possible to send a message saying it's from slimmeryetimbers.com with a DKIM check that passes for "myphishdomain.com" and DMARC will not accept it.

So has to be from one of your allowed IP addresses in the SPF record or must include a DKIM signature from your specific domain. With SPF essentially empty of options, this will mean that an aligned DKIM signature must present the for it to pass.

The dmarc policy is the "p=". A "p=none" is just for show. Doesn't enforce anything. "p=quarantine" asks the receiving mail server to put messages that fail into spam while "p=reject" tells it to not deliver them at all.

-------

So summarizing all of that...the SPF record above says that no IP addresses are allowed to send mail on your behalf and the DMARC record tells the receiving mail server not to allow any messages saying they are from your domain unless they pass the SPF check (which they can't, because nothing is allowed) or they pass the DKIM check (which they can't, because you haven't set any up).

Hope that helps and I'm happy to clarify anything that needs it.

Thank you for this answer!

A few more questions:

1. Would there be any issues receiving emails with these policies set?

2. Quoting OP's edit:

> Edit: Also, if I have a domain that currently does not send email but may in the future, am I hurting my future self by setting any of these?

None. SPF, DKIM and DMARC only affect outgoing mail.

Incoming mail is handled entirely by your mail server which is pointed to by your MX record.

This is actually where a lot of the confusion comes from. When you buy a domain, it doesn't go anywhere until you point it to specific web servers by adding A or CNAME records in your DNS. Same thing with your incoming email, nobody knows where to send a message until you setup your MX records. You can setup a web server that will serve any domain you want, but until the DNS points to it there's not an easy way for people to find it.

Outgoing mail had no such check though. Any server could send a message claiming it was from your domain unless you took the time to specify where your mail is coming from.

And no, this won't hurt you at all. All it does is tell the receiving mail servers that for an email from the domain to be valid, it must pass a DMARC check. If you subsequently setup something like Google for your domain's email, you'd just update the record by following the instructions Google will give you. For example:

"v=spf1 include:_spf.google.com ~all"

This let's Google manage the set of IP addresses. Google will likely also give you instructions to setup DKIM by adding a couple of additional records. This will ensure anything sent by Google for you domain will pass both SPF and DKIM, allowing it to be properly validated and delivered.

You'll notice that "~all" instead of "-all" as well. When you're actually sending email from the domain, it's best to use "~all" instead of "-all". The "-all" can sometimes be over zealously strict and by using "~all" instead it will be enforced but let you defer to the DMARC policy for the enforcement of failures (such as forwarding or list serves that DKIM would still survive but SPF wouldn't).

> nobody knows where to send a message until you setup your MX records

Not quite. RFC 974 says It is possible that the list of MXs in the response to the query will be empty. This is a special case. If the list is empty, mailers should treat it as if it contained one RR, an MX RR with a preference value of 0, and a host name of REMOTE. (I.e., REMOTE is its only MX). In addition, the mailer should do no further processing on the list, but should attempt to deliver the message to REMOTE.

Whether or not DMARC approves a message is based on both/either DKIM and SPF also approving. That string says that both SPF and DKIM must align and to Reject any message that fails either.

The SPF record has "-all" which means to fail any message that is not from the designated approved mailserver. Since there isn't one defined, all messages will be failed.

Having these will not impact your domain's reputation, but not having them can if you become party to spoofing. The only catch is that it will take as long as your record's TTL to make the domain sendable again, and even longer for some webmail providers who like to hang on to cached records past their expiry.

If you are at a larger company you will want to look up the rua/ruf tags and set up an aggregator because one of your other business units will totally try to send a newsletter from the domain and instruct their business partners to manually whitelist it >_>

Null MX is for positive signalling: https://www.rfc-editor.org/rfc/rfc7505.txt

For domains previously sending mail but no longer (transitioning to a new domain name), DKIM selector revocation is basically a cleaning-up (hinted at "Revoke all existing DKIM selectors in both TXT and CNAME records."). This prevents abuse at servers who don't understand DMARC but might be fooled by an errant DKIM-signed message (especially old 512-bit keys, I know key rotation but considering this is intended for government consumption there will be old systems still using a 512-bit RSA DKIM keys). This is just brownie points however if the domain never sent a valid mail at all.

That makes sense.

Here are 4 tarpit MX services which can complement the solution to absorb spam being directed at/into the no-email domain, depending on needs:

    # https://wiki.junkemailfilter.com/index.php/Project_Tar
    tar.junkemailfilter.com

    ## https://abusix.com/blackhole-mx/
    void.blackhole.mx

    ## https://www.dnswl.org/?page_id=17
    mail-in.verboten.net

    ## https://fakemx.org/
    mx.fakemx.net

Many folks like to outsource DNS hosting for smaller sites, which doesn't afford logging capabilities. Out of curiosity I chose to self-host DNS on one of my domains. I noticed many queries for MX records, and naturally assumed it was spammers looking for domains to send mail to. Looking at it again, I could see where maybe they were ultimately looking for which domains lack SPF and DKIM, perhaps checking MX first.

I understand doing this for all of your domains, but what about subdomains? I can understand the value of doing this for subdomains that were used for email in the past, but otherwise I would think setting DMARC and SPF records for every subdomain would be a real pain.

If you set them at the top level, they should carry across the subdomains unless you configure them differently or override them with a subdomain specific record.

You may want to verify that directly though. I haven't looked at the subdomain settings in a couple of years.

What if you do receive email for your domain but never for your subdomains, and therefore have necessary and non-"null" MX, etc., set up on the domain? Is there any point in having "null" records for the subdomains, and if so, is there any non-verbose way to do this?

e.g., receiving emails at [email protected], but never anything @sub1.example.com, @sub2.example.com, etc.

Use wildcard reject SPF for nameserver entries, for example:

  example.net TXT "v=spf1 include:spf.yourmailprovider.example -all"
  *.example.net TXT "v=spf1 -all"

and use strict DMARC policies. Unfortunately due to how DNS was defined, wildcard entries are not used whenever a subdomain is defined - even if its an A entry, so if you use an active subdomain (www is used most of the time) you unfortunately need to add them manually*. Also depending on your specific provider you may not be able to add them (unfortunately that's on them).

* Except on, rather surprisingly, Microsoft's DNS servers (you can tick a box to force an wildcard entry to show up even if there are records already defined).

Thanks, I do have several subdomain A records, but not a ton. I should get around to explicitly adding at least the SPF rejects for them.

I do hope that an SPF2 will allow defining subdomains. Until then, this is the best defence.

It sure would be nice if companies like Cloudflare would help offer something to this effect.

cloudflare has a point & click wizard that does exactly this, and a suggestion to use it at the top of your dns control panel.

Thanks for this!