How to align with SPF and DMARC for your domain if you use a lot of 3rd parties to send email as you

Background

One of the pieces of advice I frequently give these days to organizations is for domains to set up DMARC records, and implement a hard fail in their SPF record. This is straightforward for smaller organizations that know all of their email servers, but harder for large organizations.

Why?

Because in a large organization, there is usually no centralized person or department who is in charge of approving or organizing all 3rd party senders. For example, suppose Woodgrove Bank uses the domain @woodgrovebank.com and they are a customer of Office 365. They relay email through Office 365 from their own on-premise mail server so they set up an SPF record like this:

woodgrovebank.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 ~all"

They publish a soft fail in the SPF record which tells 3rd party email receivers that if email with @woodgrovebank.com arrives outside of the IPs defined in this record, accept the message but mark it in some way which in practice means “accept the message.” For much of the Internet, a soft fail provides very little protection.

Why the resistance to publishing a stronger SPF record, like hard fail?

The reason organizations resist is because IT departments don’t want to lose legitimate email. For example, the mortgage department at Woodgrove Bank has contracted out a 3rd party bulk email providers (for example, SendGrid) to send out email notifications to their customers who have mortages with them. They send email this way:

Sending IP: 198.37.144.99 (SendGrid outbound IP)
SMTP MAIL FROM: mortgages@woodgrovebank.com
From: Woodgrove Bank Mortgages <mortgages@woodgrovebank.com>
Subject: Refinance rates have dropped below 4%

Another department, the anti-fraud department who does credit check monitoring for customers who want to pay for it, use a 3rd party hosting service like Windows Azure to do all of their analysis, and have set up a mail server to automate when they detect fraudulent activity. They send email like this:

Sending IP: 191.235.211.144 (Azure public IP)
SMTP MAIL FROM: antifraud@woodgrovebank.com
From: “Woodgrove Bank Fraud Notification” <antifraud@woodgrovebank.com>
Subject: We have detected suspicious activity on your account

Yet another department, the one that sends out notices that a customer’s monthly statement is available. They are located in Omaha, Nebraska whereas the main office is located in San Francisco. That team has set up a mail server in the Omaha building and sends email direct to the Internet, to banking customers where their statements are ready. They send email like this:

Sending IP: 2.3.4.5
SMTP MAIL FROM: statements@woodgrovebank.com
From: “Woodgrove Bank” <statements@woodgrovebank.com>
Subject: Your March statement is available

Nobody in the IT department is sure what else is going out to the world as @woodgrovebank.com, but they do know that if spam filters start blocking their email that it will negatively affect their business. At Microsoft, we get people pinging us all the time that their email is not getting through our filters (Hotmail/outlook.com and Office 365). Businesses are very sensitive to delivery.

You can see in the above examples that none of the sending IPs are in Woodgrove Bank’s SPF record. Each of them is failing SPF authentication but fortunately, since the SPF record says soft fail, 3rd party email receivers are still accepting the message.

Unfortunately, by publishing a soft fail, spammers and phishers can similarly send messages spoofing Woodgrove Bank. This has the following negative side effects:

• Woodgrove’s customers to lose their credentials and result in the phisher stealing money
• Woodgrove’s customers may inadvertently become part of a botnet by installing malware
• Woodgrove employees themselves may be spoofed by a spear phish because the phisher is impersonating an internal message sent by another employee.

This third category is the most damaging type of phishing message.

So, how should Woodgrove Bank set up SPF records to align with 3rd parties?

Here’s how to do it [1]:

1. Set up a designated subdomain and put 3rd party IPs into its SPF record

For 3rd party mail servers, designate a subdomain such as email.<domain>, messages.<domain>, etc. Put all 3rd party mail services in there that are not under the control of the organization and update the SPF record to hard fail. This includes bulk senders as well as third party hosting services. For example:

email.woodgrovebank.com. 3600 IN TXT "v=spf1 include:sendgrid.net ip4:191.235.211.144 -all"

Anyone who sends email from these third parties must send email with an SMTP MAIL FROM of @email.woodgrovebank.com and preferably a From: address of @email.woodgrovebank.com.

Sending IP: 198.37.144.99 (SendGrid outbound IP)
SMTP MAIL FROM: mortgages@email.woodgrovebank.com
From: Woodgrove Bank Mortgages <mortgages@email.woodgrovebank.com>
Subject: Refinance rates have dropped below 4%

Sending IP: 191.235.211.144 (Azure public IP)
SMTP MAIL FROM: antifraud@email.woodgrovebank.com
From: “Woodgrove Bank Fraud Notification” antifraud@email.woodgrovebank.com
Subject: We have detected suspicious activity on your account

Sending from a specified SMTP MAIL FROM requires coordination with the 3rd parties – you must tell them to send email this way. You must also co-ordinate with the other internal teams that have chosen to use 3rd party infrastructure to send email this way, too.

You don’t have to put everyone into the same subdomain. You can use two or three different subdomains.

2. Put all the IPs you control into your organizational domain SPF record

For email infrastructure IPs that the organization controls, and Office 365 IPs (if you use it to send outbound email), put them in the organizational domain’s SPF record and set the SPF record to hard fail:

woodgrovebank.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 ip4:2.3.4.5 -all"

Anyone sending email from this infrastructure can send with the organizational domain:

Sending IP: 2.3.4.5 (IP controlled by Woodgrove Bank)
SMTP MAIL FROM: statements@woodgrovebank.com
From: “Woodgrove Bank” <statements@woodgrovebank.com>
Subject: Your March statement is available

Sending IP: 157.56.110.69 (Office 365 outbound IP)
SMTP MAIL FROM: joe.employee@woodgrovebank.com
From: “Joe Employee” <joe.employee@woodgrovebank.com>
Subject: Your March statement is available

3. Set up a DMARC record for the organizational domain

Setup DMARC records for woodgrovebank.com. If you’re not confident you’ve gotten all the sending mail servers inventoried, set up a less aggressive policy:

_dmarc.woodgrovebank.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=<…>; ruf=<…>; fo=1"

For the rua and ruf values, those are email addresses you would set up to receive DMARC feedback and aggregate reports. If you don’t want to sort through it yourself, there are some good companies out there who provide these services to help you authenticate and secure your brand.

If you’re confident you’ve gotten all the sending mail servers inventoried, set up a more aggressive policy. I would do this once you're confident all of your internal mail servers are covered by your SPF records, your 3rd party mail servers are covered by your delegated subdomain’s mail servers, and you sign your email with DKIM so that forwarded email from your domain survives forwarding.

_dmarc.woodgrovebank.com.   3600    IN      TXT     "v=DMARC1; p=reject; pct=100; rua=<…>; ruf=<…>; fo=1"

You can optionally ramp up slowly by playing around with the pct=xx value:

_dmarc.woodgrovebank.com.   3600    IN      TXT     "v=DMARC1; p=reject; pct=25; rua=<…>; ruf=<…>; fo=1"

You can also set up a DMARC record for the subdomain but it isn’t necessary unless you want it to have a different DMARC policy but that’s outside the scope of this article.

There is no additional co-ordination required with internal teams or 3rd parties. Messages coming from @woodgrovebank.com and @email.woodgrovebank.com will authenticate with SPF (and hopefully DKIM if you’ve set it up), and they will pass DMARC because you’ve already set up the delegated subdomain!

That means that the messages that come from you really do come from you – and any hacker that spoofs @your_domain will see their message rejected or marked as spam. It doesn’t matter if they spoof the SMTP MAIL FROM or the 5322.From: address. You can keep your business’s customers safe and you can keep your own internal infrastructure safe.

That is a great benefit of DMARC.

4. Add more IPs to the designated SPF records as required

Once you’ve set up SPF hard fail and DMARC reject records, no one will be able to spoof your domain unless there is a manual override like a safe sender at the receiving end. But what happens if another internal team spins up a mail server and starts sending email?

It will not get delivered.

They will then have to come to you (i.e., your IT department) and ask why their mail is not getting delivered. You can then add their IP to the SPF record if from an internal server, or to the delegated subdomain if 3rd party, and then it will work.

There’s a little bit of ramp up time but it works. And, it keeps your domain secure.

* * * * * * * * * * * * * * *

That brings us to the end of how to align your organization to properly authenticate and send email so it is secure, but also ensuring that the email you need to get delivered does actually get delivered.

I hope you find it useful.

Related links:

• Best practices for Exchange Online customers to align with DMARC
  http://blogs.msdn.com/b/tzink/archive/2015/03/03/best-practices-for-exchange-online-protection-customers-to-align-with-dmarc.aspx
  
  
• How to use DMARC in Office 365
  http://blogs.msdn.com/b/tzink/archive/2014/12/03/using-dmarc-in-office-365.aspx
  
  
• Customize an SPF record to validate outbound email sent from your domain
  https://technet.microsoft.com/en-us/library/dn789058(v=exchg.150).aspx
  
  
• How Office 365 does SPF checks for customer-to-customer mail
  http://blogs.msdn.com/b/tzink/archive/2015/02/26/how-office-365-does-spf-checks-for-customer-to-customer-mail.aspx
  
  
• Support for validation of DKIM signed messages
https://technet.microsoft.com/en-us/library/dn720849(v=exchg.150).aspx