“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 rely on DNS (domain name
system) records, and each handles a slightly different task. An SPF (Sender Policy
) 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

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 include:_spf.google.com ~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”

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

(You may need to name the TEXT record either
_dmarc.yourdomain.com 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

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

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; rua=mailto:you@yourdomain.com

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,

v=DMARC1; p=reject; rua=mailto:you@yourdomain.com

(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; rua@andy@wolberworks.com

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 wolberworks.com, 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 include:_spf.google.com include:_spf.freshbooks.com ~all

With that change, email claiming to be from wolberworks.com
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.