Found a typo?

DMARC deployment

Besides DKIM and SPF there is a third
technology that receivers use to verify whether an email was legitimate
or whether it was faked: DMARC. DMARC was invented to solve some shortcomings
of DKIM and SPF.

To understand DMARC, one must realize that new features in email are alwaysoptional. Email has been around for ages, and new technologies may not
break existing email software. This means that even though DKIM and SPF
were invented to make email more secure, it still is perfectly legal to
send emails without DKIM signatures and to send email from servers
that are not listed in SPF records. It is for example possible that the
IT department in an organization has updated its mail architecture and
ensured that everyone sends messages with perfectly valid DKIM signatures,
but that one key figure runs a mail server from her home and still sends
messages without signatures.

If a receiver gets a message from this company without a DKIM signature,
there is for this receiver no way to find out whether this mail was sent
by a malicious phisher, or by the employee who simply forgot
to update. The simple fact that a DKIM signature is missing or that there
was no matching SPF record could be an indication that something is
terribly wrong, but it could also be a small mistake. So even though
DKIM and SPF were introduced, there was still no good way to
distinguish valid mails from abuse. DMARC is a technology to solve this.

DMARC and DNS

Just like DKIM and SPF, DMARC also relies on the DNS. DMARC allows you
to add an extra record to your DNS server, and in that record you can
specify things like "Yes, all of my colleagues always send DKIM signed emails
and we all send email from servers with valid SPF records and if you ever
receive an email from my company without a DKIM signature or from a server
without SPF, just throw it away. And by the way, please keep me informed
about the messages that you throw away, so that I can check internally if
someone on the team forgot to update their computer".

That's essentially what DMARC is. It allows receivers to query the DNS, so
that they know what to do when a DKIM signature is missing or what to do when SPF
records seem to be incorrectly configured. The receiver can check the DMARC
record to find out whether this is a real indication that someone is trying
to abuse the domain, or that the company has just not completely rolled out
DKIM and SPF and that some mails might still be valid despite the mismatch.

Besides that, DMARC allows senders to receive periodic notifications
from receivers about failed checks, so that they can roll out
DMARC slowly, and get notifications if anything is wrong.

Setting up DMARC

Setting up DMARC is not always easy. The SPF and DKIM records already allow
many different parameters, and DMARC makes it only more complicated. The
SMTPeter dashboard helps you with the concept of "sender domains".
A sender domain is a domain from which you intend to send out mail.
If you use the dashboard to configure a sender domain, SMTPeter automatically
creates all the appropriate DNS records and private keys so that you can
start sending mail using that domain. You just have to copy the DNS records
that were created by SMTPeter to your own DNS server (or give them to your
provider) and you are ready to go.

Domains vs sub-domains

If you configure "yourdomain.com" as a sender domain, SMTPeter automatically
creates example DNS records for this domain. These are records for SPF, DKIM,
DMARC but also DNS records for the clicks and bounce domains. If you copy all
these records to your DNS server, you are ready to start sending email
through SMTPeter.com. But be careful!

The moment that you update the DNS records for your domain, all mails that
you do not send through SMTPeter.com are invalid. Although this does not
necessarily mean that these mails are going to be rejected (in the DMARC record
you can specify that invalid mails should initially be accepted anyway),
it is better to eventually update your entire email architecture so that all mails
are passed through SMTPeter.com and are correctly signed and sent from the
right servers.

If changing your entire mail architecture is too much of a hassle (for now),
you can take an alternative approach: you can use a subdomain for
your email deliveries. For example, if your normal mail is sent out from the
"yourcompany.com" domain name, you can use SMTPeter.com to set up a sender
domain for a subdomain e.g. "newsletter.yourcompany.com". After this setup
you can use the SMTPeter.com service for messages with a from address that
ends with "@newsletter.example.com". You still can use your current setup
to send mails from example.com.

DMARC deployment

The DMARC technology allows you to specify what receivers (companies like Google,
Yahoo and Microsoft) should do with invalid emails that (seem to) come from you. There are
three policies to choose from. The most relaxed policy is "none", which means
that you want receivers to ignore the outcome of the SPF and DKIM checks and
just put your messages in the inbox. A bit more strict is the policy "quarantine".
With this policy a failed SPF or DKIM check results in a delivered mail, but the
mail is put in a special folder, generally the spam folder. The last
policy, reject, is the most strict, and blocks the delivery for messages
with wrong DKIM signatures or that were sent from IP addresses not listed in SPF.

Besides setting the policy, DMARC also allows you to set a percentage. Say,
you set your policy to "reject" and the percentage to "25". This means that
only 25% of the mails that fail the DKIM and/or SPF checks are blocked,
and that the remaining 75 percent is still accepted. This percentage setting allows
you to experiment with deploying DMARC without having to worry that suddenly
all your mail is going to be rejected.

Given these settings, deploying DMARC is safe: you can start with a very relaxed
DMARC setting, using policy "quarantine" for only 1 percent. If things go
well you can increase this percentage up to 100 percent, and then move to
policy "reject" and start again with 1 percent that you slowly move up to 100.

The SMTPeter dashboard allows you to do this deployment automatically. You
can enter the percentage that you would like to have, and the date when you
want to have it deployed, and SMTPeter will every day automatically update your
DNS records to slowly advance to this percentage.

Processing reports

Email receivers send back daily reports to SMTPeter in which they tell
how many emails failed the DKIM, SPF or DMARC checks. These daily reports
are processed by SMTPeter and presented to you via the dashboard. It allows
you to monitor whether your configuration is valid, and/or whether your
domain is being abused.

More information

Found a typo?

Who is behind SMTPeter?

SMTPeter is made, maintained and supported by Copernica
,
a leading provider of high quality marketing software located in Amsterdam, The Netherlands.
With Copernica you can deliver relevant and timely communications using email, sms, landing pages and PDF.