SPF, DKIM and DMARC with Footer365

Adding a signature changes a message after it leaves the mailbox, so it is worth understanding what that means for email authentication. This article covers the one DNS change Footer365 asks for, and what to check afterwards.

SPF: the one change you make

Footer365's relay servers are listed in a single SPF record that Footer365 maintains:

include:_spf.footer365.net

Footer365 keeps the addresses behind this include up to date as relay servers are added or removed, so you add it once and never change it again.

Where it goes

The include goes into the existing SPF record of each custom domain you send from, before the final all mechanism. A domain can only have one SPF record, so add it to the record you already have rather than creating a second one.

Keep everything else in your record, including entries for other systems that send as your domain, such as a gateway or a marketing platform.

No .onmicrosoft.com domain is included, whether it is your initial domain or another one, because its SPF record is managed by Microsoft and cannot be edited. Footer365 never checks or lists them.

The portal tells you what to publish

While any of your email-enabled custom domains is missing the include, the portal shows Action required: update your SPF record. For each domain it shows the record currently published and the exact record to publish instead, with a Copy button. The banner clears itself once the change is detected. Step-by-step instructions are in Update your SPF record.

DKIM

A DKIM signature covers the message body. Adding a signature changes the body, so a DKIM signature applied before the relay no longer matches, and a receiver would report dkim=fail.

To avoid that, the relay removes any DKIM-Signature header from a message when it writes a signature into it. On messages it hands back unchanged, for example a protected message or one no rule applies to, the relay adds only its own trace headers and leaves any DKIM signature alone, because adding headers does not break DKIM.

What the recipient finally sees depends on what signs the message after it leaves Footer365. If you have DKIM signing enabled for your domain in Microsoft 365, or a gateway after Exchange that signs, check a received message rather than assuming: open the headers of a message sent to an external mailbox and look at the Authentication-Results header for dkim=pass and the domain it names.

For how to enable DKIM for a custom domain in Microsoft 365, see Microsoft's guide: Use DKIM to validate outbound email.

DMARC

DMARC passes when either SPF or DKIM passes and the domain it passes for matches the domain in the visible From address. With Footer365 in place:

• SPF alignment relies on your SPF record authorising the servers that send for your domain, which is why the Footer365 include matters alongside Microsoft's own.
• DKIM alignment relies on a DKIM signature for your own domain being present on the delivered message, as described above.

Checking it

1. Send a message from a mailbox covered by a Footer365 rule to an external mailbox you control, for example a personal account.
2. Open the received message's headers and find Authentication-Results.
3. Check spf=, dkim= and dmarc=, and which domain each result names.
4. Confirm X-Footer365-Relay-Id is present, so you know the relay handled the message you are looking at.

If you publish DMARC aggregate reports (rua=), review them for a week or two after going live. They show which sources are sending as your domain and whether each passes.

Related

• How mail flows through Footer365
• Using Footer365 alongside another email gateway
• Microsoft: Set up SPF to identify valid email sources
• Microsoft: Use DMARC to validate email