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.

The solution for authenticating 3rd parties

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.

Agari http://www.agari.com
ReturnPath http://www.returnpath.net
DMARCIAN http://www.dmarcian.com

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:


[1] This is my personal recommendation, it has not been officially reviewed by Microsoft. But the policy I recommend is how Microsoft does it, and it’s one of the options on the dmarc.org website.

Comments (13)

  1. MikeG says:

    Great reference article. This will help me clamp down some loose ends. Appreciate the time you took to post it! Thanks!

  2. Mike says:

    Finally.. an article that's straightforward and gives concrete examples for 3rd party senders! I've been looking for something like this for a while 🙂  Thanks very much!

  3. Tinus says:

    I wonder if you can advise me, we are using MS exchange 2010 with an edge server and my internal domain differs from external domain, the edge although not on the domain, primary suffix is that of internal domain, now I am getting spf ndr as it does not recognize my internal domain, if I change the primary suffix to external domain AD does not allow the edge server to send and receive mails internally.

  4. Vishnu N says:

    Hi. One of the best articles out there explaining DMARC setup for 3rd party emailing. But one question I have is that, if we setup hard fail for SPF, how does it effect the forwarded emails? Forwarded emails will have SPF fail in such cases. How do we deal with that? Thank you.

  5. John says:

    I am facing a similar issue with 3rd party senders. One question though, what if internal staff want to receive the replies back sent by the 3rd party? Say the third party sends as john@email.abc.com. If John requires to receive the email. The email.abc.com sub domain would need to be added to exchange and johns mailbox stamped with john@email.abc.com. Alternatively the 3rd party chooses a different "reply to address"

    The above could be a lot of work compared to adding the 3rd parties to the main SPF?
    Which may need to be daisy chained because of the spf lookup limit.

    Does anyone have any thoughts on this issue?

    Thanks

    John

  6. Sam Thackeray says:

    Very helpful although i have a question.

    We are looking to implement an an alias domain and add DKIM and DMARC to the original as the guide suggests in an effort to reduce the chance of phishing emails but my question is what is there to stop the phishers from then just emailing using the alias domain rather than our primary one?

    Thanks,
    Sam

    1. tzink says:

      DMARC covers all of your subdomains if you publish a policy at the root (organizational) domain *unless* you publish one explicitly at that subdomain, or specify a subdomain policy in the organizational domain. For example:

      example.com "v=DMARC1; p=reject"
      foo.example.com "v=DMARC1; p=none"

      If a phisher spoofs @example.com, or @bar.example.com, this will fail DMARC and get rejected. But if they spoof @foo.example.com, it will fail DMARC but be treated with p=none (no special action";

      If you want every single subdomain to have its own policy and treat it as p=none, you can specify that in the organizational domain:

      example.com "v=DMARC1; p=reject; sp=none"

      In general, I don't recommend a subdomain policy; just let them inherit from the parent domain. For the ones that shouldn't inherit, set it up explicitly.

  7. NEERAJ SHAH says:

    Dumb Question, For authenticating 3rd parties, are we supposed to implement any one of the 3 options listed above or all the options ?

    1. tzink says:

      Only one of them is required.

  8. Mark says:

    Awesome article, thanks, and still useful 20 months later! 🙂

    I have a related question, though coming from a different angle. I work for a 3rd-party ESP (like SendGrid). While I understand the benefits of strict and aggressive policies for protection, I'm wondering if they help deliverability to the inbox. That is, do Gmail, Yahoo, AOL, etc., weigh those stricter policies as benefits when considering where to send the email (inbox, spam, rejection, etc.)?

    1. tzink says:

      Sort of.

      The lack of a strong policy can affect delivery but in ways different than you think. We had a case in Outlook.com/Hotmail where a charitable organization was getting sent to the spam folder. When we investigated why, it's because spammers were spoofing the sending domain and users kept marking it as Spam. The training system learned that this particular sending domain was spam, so when the actual domain (which published no auth policies) sent legitimate mail, it was marked as spam.

      Had SPF/DKIM/DMARC been published, the system would have been able to keep the junk out so that the legitimate domain's reputation could not be hijacked and degraded.

  9. John says:

    Hi Terry,
    Following your extremely helpful advice on this topic (thanks), I have implemented the following for our parent domain of abc.com.
    The SPF record for abc.com has our on-premises mail servers and Office 365 SPF record set with a hard fail.
    The 3rd parties have all been contacted and are sending email as mail.abc.com (The SPF record for mail.abc.com includes the 3rd parties mail servers IPs / Their SPF records)
    We have stamped a secondary alias on all our recipients with than alias of user@mail.abc.com should they receive a response to any emails sent by the 3rd parties. The reply will be sent from the user@abc.com email address.
    We have a requirement that our parent domain has to use DKIM and DMARC to meet some guidelines.
    I have read your other blog posts on this subject and as I understand it, DMARC will apply to the parent domain and sub domains.
    I am not too concerned about building email reputation for the sub domain, our internal users won’t be sending email out as the email.abc.com domain only receiving.
    Based on the above:
    Can DKIM be configured for the parent domain only?

    What would you recommend for configuring DKIM for the sub domain if I wanted to approach that a later date?

    We have roughly 5 to 6 3rd parties sending email as the sub-domain at the time of writing.

    Thanks

    John

Skip to main content