Ultimate Guest List: Securing the “Inbox Party” with SPF, DKIM, and DMARC

Imagine you’re throwing a super exclusive party (aka your inbox), and you want to make sure only the coolest and most legit guests (aka emails) make it through the door. SPF (Sender Policy Framework) is your bouncer at the door checking the guest list (aka IP addresses authorized to send emails from your domain). If the sender’s IP isn’t on the list, SPF’s like, “Sorry … not on the list, not getting in.”

DKIM (DomainKeys Identified Mail) is all about making sure the invite (aka the email) hasn’t been tampered with on its way to the party. It’s like your guest invitations having a unique seal or stamp (aka a digital signature). DKIM checks the invite to ensure the seal matches the one on file, proving the message is legit and hasn’t been messed with.

Then we have DMARC (Domain-based Message Authentication, Reporting, and Conformance), the mastermind coordinating SPF (aka the bouncer) and DKIM (aka the validator) efforts. DMARC is like your [aggressive] party planner ensuring the guest list and invite seals are used correctly. It tells the email receivers what to do if an email fails the SPF or DKIM checks, and provides reports back to the sender (you, the host) about who’s trying to crash the party using their name.

Why does all this matter? Well, it’s all about trust and security. By implementing SPF, DKIM, and DMARC, domains make it super tough for imposters to send scammy emails pretending to be YOU. It’s like ensuring your exclusive party stays exclusive, fun, and, most importantly, safe for all your legit guests.

Get the party started (p.s. If this is too much to take on, WTG Services is always there to help!)

1. It would be hard to imagine you NOT having an SPF record at this point, so let’s start with that. Take a look at your SPF record and use that to determine which Email services leverage your domain for sending. Probably M365, Mimecast, Proofpoint, and systems like CRM or ConstantContact/Mailchimp. This is now the list of services you need to configure DKIM for/on. Incidentally, many of the bulk mailer services are nearly requiring you to use one of their domain names. If you are operating your own bulk mailer or one that uses your services (such as Outreach), consider using an alternative domain name for bulk mail.

2. Look up the DKIM setup information for each of your service. They all generally work the same way, but the interface is often different. Your provider will instruct you on what record to create and the values for that record (or records). In M365, for example, you can start by going to you DNS settings, select your domain, open Advanced Options and check off “DomainKeys Identified Mail”. It will show you exactly what DNS records to create. You’re going to want to create the DNS records that your provider instructs you to create for EACH of your services. Often times, for redundancy and key rotation, providers have more than one value (or selector) for each domain name you’ll have. Go over to your DNS management (AWS, Go Daddy, whatever) and create the records.

So, for M365 and for winslowtechgroup.com, we have (literally, you can check on mxtoolbox):

selector1._domainkey as the DNS record, type=CNAME, and value = selector1-winslowtechgroup-com._domainkey.winslowtechgroup.onmicrosoft.com

and

selector2._domainkey as the DNS record, type=CNAME, and value = selector2-winslowtechgroup-com._domainkey.winslowtechgroup.onmicrosoft.com

These CNAMEs point to an address where the Email server can obtain the domain key.

Alternatively, you may be instructed to create the record as a TXT with the key value, as is the case with Mimecast: mimecast2024021601._domainkey as the DNS record, type=TXT, and value = v=DKIM1; k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCH8DAHfjhoV42CjLrpSqejzfiGKdO3X+
C02h8AAFjGxRbvIS8jJUc2h8YVUUw7NYxtcXc9FqDYDYarf/dVpW3YWD12uL2gp9zlBkpIAfV72Es/
KBr7sdOfT9s60HLVRQtBnLha7uvSqXkr3Jp+y9efGk4Njx3n3KnjhxPDwIy5YQIDAQAB

You can test this with a site like mxtoolbox. Your DKIM selector is the first part, before the ‘.’, in ._domainkey. That should validate the record and eventually get you to an RSA-style key. If you have a few domain names, a few services, and 2 selectors per service you may end up with a bunch of records. That’s OK – be patient and pay attention to detail.

3. Once the records are setup, you need to “enable” the service in your applications. Often this is in the same spot that helps you generate the DKIM record. Your service validates the record and then enables DKIM services. Sometimes, it takes a while for your service provider to get the new domain settings. Note that, in Microsoft M365, the setting is in Microsoft Defender -> Policies & rules -> Threat policies -> Email authentication settings. Similarly, in Mimecast, you will create the policy definitions for each domain name (Policy Definitions -> DNS Auth – Outbound) DNS, and then you need to also create an Outbound DNS authentication policy for each DKIM signed domain for it to work correctly. If you send a test email off to say a Gmail address (or similar) you should see that the message was “mailed-by” your domain and “signed-by:” your domain name (they should match). This is an easy way to know it’s working (thanks Google/Gmail!).

4. Final[ish] piece here! Once you’re comfortable with your SPF and DKIM records (the most painful part is logging into your various services), you “ice the cake” (as they say) by instructing other organizations to take certain action, depending on what they “see”. This is what the DMARC record is for. Basically, the DMARC record says authenticate “this domain” (i.e. YOUR domain) in this way and take this action if authentication fails. What’s pretty amazing is that you will get reports to understand the impact of your SPF and DKIM records in the wild… Like the [aggressive] party planner, DMARC ties this all together.

The first phase of this should be to do nothing. You’re going to create a shared mailbox (or similar) or subscribe to a service (like Mimecast’s DMARC Analyzer). That’s going to be the recipient of the XML reports coming in from the wild. The DMARC record is a _dmarc.YOURDOMAIN.COM TXT record. A basic one looks like this: “v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com”. The “p” is the important part – that’s the policy or action to take if a message fails DMARC. You always start with “none”. This way you can get a feel for how successful your SPF and DKIM deployment was, and what impact changing that from none to quarantine/reject would have.

Specifically, you’re going to look for records that show pass/fail. In this example DKIM wasn’t working correctly, and I recognize (via ARIN lookup) that the 170.10.133.115 address is Mimecast – so this means I need to look at my Mimecast configuration for an error in the DKIM definition or policy itself.

170.10.133.115
1

none
fail
pass

Once you’re comfortable with the results you see from the reports coming in, you can contemplate moving this from “none” to “quarantine” (the suggested option). There are other options on DMARC, but for the sake of simplicity don’t worry about them until you have to!

There is a slight “complication” with automated replies including NDR (non-delivery reports), “Out of Office” and other “Autoreply” messages, whereby the return path header ends up being blank.  This poses a challenge for DMARC, since your Email provider may not be able to correctly attribute the correct domain and DKIM records to it.  Specifically, the header to look for is  “Return-Path=<>”. This would make your OoO and other messages failing DMARC and ending up rejected or in quarantine.  During your testing, you should thoroughly test Out of Office and ensure the domain name and DKIM records are 100% correct, so it passes DMARC checks.  This is especially true if you, like we, have multiple Email domains.  If you’re using Mimecast, for example, to accommodate this you want to have your “Outbound DNS Policy” to have “Emails From”, “Addresses Based On” set to both (this applies the policy based on either the Mail Envelope From or the Message Header From whichever matches. When both match the specified value the Message Header From will be used).