Reduce spoofed email from your domain with DMARC

SPF, DKIM, and DMARC make it difficult for spammers to send fake messages that appear to have been sent by your organization.

"Spoofed" spam is email that appears to be sent from a legitimate account, but wasn't. You certainly don't want your customers to receive spoofed email appearing to have been sent from your organization. Fortunately, you can reduce spoofing from your account with three settings: SPF, DKIM, and DMARC.

SPF, DKIM, and DMARC rely on DNS (domain name system) records, and each handles a slightly different task. An SPF (Sender Policy Framework) record indicates which mail servers are authorized to send email for a domain. A DKIM (DomainKeys Identified Mail) record adds a digital signature to emails your organization sends. A DMARC (Domain-based Message Authentication, Reporting and Conformance) record defines how to handle mail: it tells mail servers what to do with email that fails SPF and DKIM tests.

SPF and DKIM records are validation signals. You might think of them as "rules" that enable other email servers to judge whether or not a received email is legitimate. As email arrives, the receiving mail server can use these records to validate that an email was sent by an authorized mail server (SPF). The receiving mail server can also validate that an email is properly digitally signed (DKIM).

A DMARC record provides "sentencing guidelines" to other email servers: it advises a mail server how to handle email that fails SPF and DKIM validation tests. DMARC considers a message "valid" if it passes ONE of these tests. DMARC provides three "sentencing" options for email that fails both tests:

  • monitor (do nothing),
  • quarantine (mark the email as spam), or
  • reject (cancel the email).

Just as not all judges follow sentencing guidelines, not all mail servers will honor your DMARC record. However, many large email providers support DMARC, including Google, Microsoft, Yahoo!, AOL and Comcast. As of February 2013, the DMARC working group announced that "the DMARC standard now protects almost two-thirds of the world's 3.3 billion consumer mailboxes worldwide." DMARC is widely used, but not universally deployed.

Here are a few things to consider when enabling DMARC for your domain.

Set up SPF, DKIM, and DMARC for Google Apps

Note: To fully configure SPF, DKIM and DMARC for a Google Apps domain, you'll need administrative access to the domain's Google Apps admin account and domain name registrar. Remember that DNS changes may take several hours to be reflected across the Internet.

1. Create SPF and DKIM DNS records.

Configure SPF and DKIM for your domain by following the steps in my earlier post: "Send better email: SPF and DKIM for Google Apps". Essentially, you do two things:

a. Enable SPF by adding a TEXT record to your DNS settings:

v=spf1 ~all

b. Enable DKIM by generating a DKIM key within Google Apps, then adding a TEXT record with the generated key and value to your DNS settings. Once the DNS record has been added, return to Google Apps to validate that the DKIM key is present, then turn DKIM authentication on.


At your DNS host, create SPF and DKIM records

2. Create a DMARC DNS record.

Add a TEXT record to your DNS settings to provide "sentencing guidelines" for mail. The format for a basic DMARC record set to "monitor" is:

v=DMARC1; p=none;

(You may need to name the TEXT record either or _dmarc. See your DNS host's documentation, as DNS management interfaces vary.)

The v indicates DMARC version, p indicates the policy. The "p=none" indicates that we want to receive DMARC reports. The "rua=" indicates where aggregate reports should be sent, which is most likely your email address.

3. Receive DMARC reports.

Once your DMARC DNS record is active, you will receive DMARC reports from mail providers that support DMARC. Report details will be provided in an .XML file in compressed .ZIP format. Unzip the file, then view the contents. (Chrome OS tip: Chromebook users will see an error when trying to open an .XML format file. Rename the file from ".xml" to ".txt" to view the contents.)


DMARC reports offer a window into the sources of sent email from your domain

The DMARC report displays the source and domain header information for each email, along with results of SPF and DKIM validation tests. The source IP address helps identify the source of email: a great deal of email should appear to be sent from your location's IP address. Pay attention to records where either SPF or DKIM indicates a rejection or failure.


Excerpt of the information you'll see in a DMARC XML report

I recommend you create filters or rules to avoid flooding your inbox with DMARC notifications. I filter using the "from:" email address for AOL, Comcast, Google, Microsoft and Yahoo, setting the email to "skip the inbox" and apply the label "dmarc". See my sample Gmail filter settings.


Set up filters to move DMARC reports out of your inbox automatically

4. Ratchet up DMARC settings gradually.

We want to avoid rejecting valid email, such as that sent by a third-party provider. The larger the number of users, the more difficult it becomes to identify all of the valid third-party sources of email. Avoid rejecting legitimate email by gradually increase the "punishment" for invalid email over time: moving from "monitor" to "quarantine", then finally to "reject".

To "quarantine" email that fails both SPF and DKIM tests, use a DMARC record format of:

v=DMARC1; p=quarantine; pct=50;

Note that "pct=" represents the percentage. In this case, 50% of email that represents itself as being sent from your domain, but fails the DKIM and SPF checks, will be quarantined. Note that "quarantine" means the mail server will mark the message as spam, which makes the email likely to be caught in spam filters or folders.

To reject all email that fails both the SPF and DKIM tests, use:

v=DMARC1; p=reject;

(Google provides a suggested deployment cycle near the bottom of its "Create a DMARC record" support page.)


Eventually, you'll want to reject all email that doesn't pass DMARC

5. Approve additional other senders, as needed.

You may need to authorize additional email senders to ensure email delivery from third-party services, such as emailing services and web apps. For example, I use Freshbooks for invoicing. Freshbooks sends an email when I create an invoice. I have my DMARC record configured to reject email:

v=DMARC1; p=reject;

When I invoice a client from Freshbooks, the service send an email to my client. DMARC rejected the email, since the email claimed to be from, but was sent from Freshbooks: it failed both the SPF and DKIM validation tests. DMARC rejected the email and notified me.


Sample email notification of an email rejected due to DMARC

To authorize Freshbooks to send email representing itself as from my domain, I modified my SPF record to be:

v=spf1 ~all

With that change, email claiming to be from sent via Freshbooks or Google will pass the SPF test. Remember, email must pass either the SPF or DKIM test to pass the DMARC test.

Be sure to inform people when you configure DMARC to quarantine or reject email. Either stage may result in email "not going through" or being tagged as "spam", especially when using third-party services. If people are informed that you're deploying DMARC to help reduce spam, they'll be better prepared to "re-send" after you've made appropriate SPF DNS record changes. (Note that DMARC may be used as a way for IT to prevent unauthorized use of third party services that send email on the domain's behalf!)

Less Spam, please

SPF, DKIM, and DMARC don't solve all spam problems: spammers can still send email that people didn't ask for and don't want. But these tools do make it difficult for spammers to send fake messages that appear to have been sent by your organization. If you manage email for a domain, you owe it to the rest of us to use SPF, DKIM, and DMARC.