Deploying DMARC to prevent email spoofing is a no-brainer. No one wants spoofed email from @yourdomain.com that could easily lead to a successful phishing attack or business email compromise (BEC). But have you deployed DMARC (Domain-based Message Authentication, Reporting and Conformance) for domains you own that do not send or receive email?
Consider this: If you run acmecorp.com, maybe you also own acnecorp.com. Not saying your complexion is poor, but it's a good typosquatting purchase, and a cheap insurance policy against phishing or impersonation. With DMARC deployed for acmecorp.com, spoofed emails like IAmTheCEO@acmecorp.com are toast. What about a spoofed email from acnecorp.com? You see the problem.
Publishing a DMARC record that says, "Yo, world! This domain is never, ever used for email, and if you ever get email from this domain, it is by definition not genuine" is the best way to prevent this kind of attack.
How to turn off email for parked domains
It might seem counterintuitive: Why publish a DomainKeys Identified Mail (DKIM) record in your DNS if you're never going to cryptographically sign outgoing email? Why publish a Sender Policy Framework (SPF) record if there will never be genuine email coming from your domain? It's a hack, that's why. We've been trying to back-port security onto email for 40 years and still can't get it quite right.
Combined with a DMARC record and a null mail exchanger (MX) record, these are the best practices for preventing spoofed mail being sent by a fraudster using a domain you own. Want to go deeper? The authoritative guide to securing email for parked domains can be found in this anti-spam working group document, the Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG) from December, 2015, entitled "M3AAWG Protecting Parked Domains Best Common Practices". If you need a primer on DMARC, DKIM and SPF, check out this CSO article.
SPF for parked domains
SPF prevents fraudsters from sending email from a domain they don't own because you, as the domain admin, are going to publish a DNS TXT record telling the world which hosts may send email on behalf of that domain. Email service providers, when they receive an email, then check that DNS entry to see if the host in question is authorized.
Publishing an SPF record that says, "Nope, nosirreebob! There are ZERO hosts allowed to send email on behalf of this domain," will cause most email service providers to flag such bogus email as spam.
Correctly configuring a parked domain's SPF to prevent email spoofing goes like this:
```
example.com. TXT "v=spf1 -all"
```
What does this mean? For the domain example.com, the “-all” hard fail directive strictly enforces SPF, and the absence of an "include:example.com" directive says there are no legitimate domains this mail should come from.
The authoritative source (see end of article) also recommends nuking subdomains in your parked domain SPF record to prevent email spoofing from @spam.example.com and @phishing.example.com:
```
*.example.com. TXT “v=spf1 -all”
```
DKIM for parked domains
Most email providers these days enable DKIM, where the email server cryptographically signs outgoing emails using a private key, and the matching public key is published in the domain's Domain Name System (DNS). DKIM lets receiving email servers know that the incoming email comes from the server it claims to come from, and that the message has not been modified in transit.
How does this help prevent unwanted spoofed email on a parked domain? RFC 6376, which governs DKIM, stipulates that an empty value for the public key ("p=") means that "this public key has been revoked." This has the de facto consequence of being a public declaration that no valid DKIM exist for this domain, and all DKIM checks by receiving email servers should fail as a consequence.
```
*.example.com. TXT “v=DKIM1; p=”
```
Unlike SPF, which requires two DNS entries, this DKIM record says for both domain and subdomain level email hosts that any email sent (spoofed) from those domains should be considered bogus.
DMARC for parked domains
In the beginning, there were SPF and DKIM, and they were found to be hacky and not good enough to prevent email spoofing, for reasons too lengthy to explore in this article. And then behold! There was DMARC, and lo unto many it seemed to them good.
DMARC ties SPF and DKIM together in two ways. First, a domain publishes a DMARC record as a public statement of what should happen to email that fails both SPF and DKIM checks. Monitor only ("p=none")? Quarantine as spam ("p=quarantine")? Reject outright ("p=reject")? Second, DMARC forces SPF and DKIM alignment, which typically means including senders like Mailchimp, Zendesk and other third-party email senders in your SPF record.
With a parked domain, though, the goal is to tell the world that all email from acnecorp.com is bogus and requests receiving email servers to treat such email with extreme prejudice. So, let's cobble the SPF and DKIM records together and publish our DMARC record to the world: "We publicly declare that no email ever legitimately comes from @example.com, and if you get some, reject it and tell us about it."
```
_dmarc.example.com TXT "v=DMARC1; p=reject;
rua=mailto:rua@example.com; ruf=mailto:ruf@example.com”
```
An email server that received email from acnecorp.com would check SPF and DKIM, both of which would fail, and then examine the DMARC record, which is a 100% "p=reject" policy. In a perfect world, such email would bounce. In reality, most email service providers interpret "reject" as "quarantine with a high spam score."
What about those rua and ruf email reporting addresses? DMARC won't work out of the box if you ask for reports to be sent to a domain other than the one right in front of you. But you can use a CNAME record to specify reporting using a different domain's DMARC rua and ruf reporting addresses.
```
_dmarc.example.com CNAME _dmarc.parked.example.net.
_dmarc.parked.example.net TXT "v=DMARC1; p=reject;
rua=mailto:rua@example.net; ruf=mailto:ruf@example.net”
*._report._dmarc.example.net TXT “v=DMARC1”
```
Now your DMARC reporting for a parked domain will go to the reporting address listed for your real live email domain.
Publish a null MX record
One final bit of due diligence to clobber spoofed email on parked domains is to double down with a null MX record, as specified by RFC 7505.
```
example.com MX 0.
*.example.com MX 0.
```
The first line tells the world that no email service is available for the domain. The second line says no email service is available for any subdomains as well. Be careful about using null MX records, though. "As of late 2015, M3AAWG recommends the use of a null MX record only if the domain has an A and/or AAAA record for maximum compatibility with receivers who have not yet implemented the standard."
Registering typosquatting domains is a cheap insurance policy against phishing attacks and reputational damage from spoofed email, but your job isn't done until you turn off all email for those domains as well. Proper SPF, DKIM, and DMARC settings will go a long way toward preventing email spoofing.
The M3AAWG tells CSO that they plan to update their recommendations this year, but said there won't be any new best practices. As for null MX records, they've "increased in absolute numbers, but.... [not] enough to be noteworthy - and not in proportion to the number of domains.”