Align

Alignment is where most DMARC projects stall. You have published a record, you are watching the reports, and now you have to make every legitimate sender pass before you tighten the policy. This is the longest and most hands-on part of the work, because alignment is decided service by service, and each one has its own way of doing it. The goal is simple to state and fiddly to reach: every real email from your domain must pass DMARC through aligned SPF or aligned DKIM, so that when you move to p=reject, nothing legitimate breaks.

What alignment actually means

DMARC does not just ask whether SPF or DKIM passed. It asks whether the domain that passed matches the domain your recipients see in the From header. That match is alignment, and it is the part people miss.

Take an invoice sent from accounts@yourcompany.com through a billing platform. SPF might pass, but if it passes on the platform's own return-path domain (something like bounces.billingvendor.net), the SPF-authenticated domain is the vendor's, not yours. SPF passed; SPF alignment failed. DMARC checks both SPF alignment and DKIM alignment, and it only needs one of them to pass. So a message can sail through SPF or DKIM checks and still fail DMARC outright because neither aligned with yourcompany.com.

There are two alignment modes. Relaxed alignment (the default) accepts the organisational domain, so mail.yourcompany.com aligns with yourcompany.com. Strict alignment demands an exact match. Almost everyone uses relaxed, and you should too unless you have a specific reason not to.

Two roads to a DMARC pass

A message passes DMARC if either aligned SPF or aligned DKIM passes. You do not need both. In practice we aim for aligned DKIM on every service, because DKIM is the more durable of the two.

SPF does not survive forwarding. The moment someone forwards your mail, or it passes through a mailing list, the connecting IP changes and SPF breaks. DKIM travels with the message, because the signature is part of the message itself. If you can only fix one path per service, fix DKIM. We still repair SPF as well, because some recipients lean on it and because a clean SPF record is part of the Google and Yahoo bulk-sender requirements that took effect on 1 February 2024.

The SPF work: getting under ten lookups

SPF has a hard ceiling. RFC 7208 limits an SPF record to ten DNS lookups during evaluation. Each include:, a, mx and redirect counts, and nested includes count too. Go over ten and the result is permerror, which makes SPF fail for everyone, not just one service.

This is easy to trip. A record that lists Microsoft 365, a marketing tool, a help-desk product and a CRM can quietly resolve to eleven lookups and return permerror. We do three things:

• Flatten. We resolve the include: mechanisms down to their current IP ranges and publish those ranges directly, which collapses many lookups into one. Because vendor IPs change, flattening has to be monitored and refreshed, not done once and forgotten. Our SPF flattening keeps the resolved record current automatically.
• Remove the dead includes. Most domains carry includes for services they stopped using two years ago. An old newsletter tool or a trial CRM still sits in the record, burning lookups for nothing. We audit every mechanism against the senders we actually see in the aggregate reports and drop what no longer sends.
• Fix the single-record rule. A domain may publish exactly one SPF TXT record. Two records (often the result of two teams each adding their own) is itself an error. We merge them into one valid v=spf1 record.

We also set the right ending. -all (hard fail) tells receivers to reject anything not listed; ~all (soft fail) marks it suspicious. During alignment work we are careful about which one is live, because SPF and DMARC interact, and we tighten the ending in step with the policy.

The DKIM work: sign with your own domain

DKIM is the road that survives forwarding, so this is where we spend most effort. DKIM adds a cryptographic signature in the DKIM-Signature header, and the matching public key lives in DNS at <selector>._domainkey.yourcompany.com. Alignment depends on one field in that signature: the d= domain. For DKIM to align, d= has to be your domain.

Many services sign by default with their own domain. Your mail goes out signed by d=sendingvendor.com, DKIM passes, and DMARC still fails because the signature is not aligned with your From address. The fix is to configure each service to sign with a custom signing domain, which means generating a key, publishing the public half at a selector under your domain, and switching the service over to sign as you.

While we are in there, we do two more things:

• Move to 2048-bit keys. Plenty of older setups still use 1024-bit keys. Where a service supports it, we publish 2048-bit keys, which is the current expectation.
• Set up selectors for rotation. The selector (for example s1._domainkey) lets you run more than one key at a time and rotate without downtime. We name selectors clearly per service and per generation, so you can retire an old key by adding the new one first, moving signing over, then removing the old record once no mail relies on it.

The per-service reality

Here is the part nobody warns you about. There is no single switch. Every SaaS sender that puts your domain in the From line has its own console, its own wording and its own steps for adding a custom signing domain. One product calls it "authenticated domains", another "sending domains", another "branded links". Some let you set a custom return-path for SPF alignment too; some do not.

We work through them one at a time. We use your aggregate reports to build the full list of sources sending as you, then for each one we enable DKIM, point it at your domain, verify it in the reports, and move on. A typical organisation has between six and twenty distinct sending services once you count the obscure ones, like the e-signature tool or the appointment reminder nobody remembers signing up for.

Common services and the alignment fix

The exact field names move around as vendors update their interfaces, so we follow each provider's current documentation rather than trust a screenshot from last year. What stays constant is the test: after the change, does the aggregate report show this source passing DMARC with aligned SPF or aligned DKIM? If yes, it is done.

Verifying with aggregate reports

You do not declare alignment finished by feeling confident. You read the rua= aggregate reports and watch the pass rate per source climb. The reports group mail by sending IP and source, and for each one they tell you whether SPF aligned, whether DKIM aligned, and what DMARC concluded.

We track each legitimate source until it reports effectively 100% DMARC pass across a stable window of reports, not just a single good day. A source that passes on Monday and fails on Wednesday usually means a second, unconfigured route exists (a secondary IP pool, a forgotten sub-product, or a region-specific server). We chase those down too. Only when every known-good source is consistently passing do we consider the domain ready to tighten.

Reading these reports by hand is grim. The platform parses them for you, names the sources in plain language, and shows the pass trend per sender, which is what turns a months-long slog into a tracked checklist. This is the same data the earlier audit step used to build your inventory, now read for a different purpose.

Senders that cannot be aligned

Some sources will not align no matter what you do. A legacy application might send through an IP you cannot configure for DKIM. A third-party tool might offer no custom signing domain. A forwarding arrangement might break both SPF and DKIM in flight. You cannot let these block enforcement on your main domain, and you should not weaken your policy to accommodate them.

The answer is to move them off the parent domain. Two patterns do most of the work:

• Subdomains. We give the awkward sender its own subdomain, for example notify.yourcompany.com or mailer.yourcompany.com, with its own DMARC record and its own SPF and DKIM setup. The parent domain can then go to p=reject while the subdomain runs at a looser policy until it is sorted, or stays at a policy appropriate to its risk. Because DMARC alignment is relaxed by default, mail from the subdomain still authenticates cleanly under it.
• Dedicated sending streams. For bulk or transactional mail at volume, a dedicated subdomain (such as email.yourcompany.com) keeps that traffic separate from your corporate mail. It isolates reputation, it makes the reports easier to read, and it means a marketing platform's quirks never threaten the deliverability of an invoice or a contract.

A small number of senders are genuinely retired during this work, because the cleanest fix for a tool nobody uses is to switch it off. Each one removed is one less thing to align and one less risk at enforcement.

How long this takes

Alignment is measured in weeks, not minutes, and the timeline is set by your service count and how fast DNS and vendor changes propagate. A simple organisation on Microsoft 365 with two marketing tools might be aligned in a fortnight. A larger one with twenty sending services takes longer, because each service needs its own change, its own verification window, and a few days of reports to confirm.

The discipline that makes this work is refusing to move forward on assumption. Every service is verified in the reports before it is ticked off. That is what lets the next step happen safely.

Why this step gates enforcement

The reason alignment comes before policy is mechanical. At p=none a failing message is delivered anyway, so an unaligned sender is invisible to your users. At p=reject that same unaligned message is refused. If you tighten the policy before alignment is complete, the senders you missed are the ones that break, and they are usually the quiet, important ones.

This is also where the compliance value gets locked in. The Google and Yahoo bulk-sender rules, Microsoft's high-volume requirements for Outlook.com and Hotmail that the company began applying through 2025, and PCI DSS 4.0 requirement 5.4.1, mandatory since 31 March 2025, all assume your legitimate mail authenticates and aligns. Get alignment right and every one of those follows.

Alignment is the unglamorous middle of a DMARC rollout and the part that decides whether the whole thing works. It is hands-on, service by service, and proven in the reports rather than assumed. Once every legitimate source passes consistently through aligned SPF or aligned DKIM, the awkward senders are parked on subdomains, and the aggregate reports are clean, you are finally ready to move the policy to enforcement. That is step three, and by the time you reach it the risky work is already behind you. Start with a free scan of your domain, or create an account.