Why email aliases break SPF, DKIM and DMARC alignment

SPF and DKIM authenticate a sending *path* and a cryptographic *signature*, not a human-readable alias name. An alias is just a display convenience on the From header; if the actual transport sending on its behalf was never registered in SPF, or never configured with a DKIM key for that domain, every message fails authentication regardless of how official the alias looks to the recipient.

The three checks and where an alias breaks each one

SPF checks whether the IP that connected to the receiving server is authorised to send for the domain in the envelope-from (MAIL FROM), not the visible From header. If your alias sends through a tool or relay whose IP range was never added to your domain's SPF record, SPF fails for that message - full stop, regardless of how the alias is configured on your mailbox provider's side.

DKIM checks a cryptographic signature against a public key published at a selector under your domain. If the sending platform behind the alias does not have a DKIM key configured for your domain (or signs with a key for a *different* domain than the one in the visible From header), DKIM either fails or simply does not apply - and in either case, it does not count toward alignment.

DMARC does not check SPF or DKIM pass/fail directly - it checks whether the *domain* that passed SPF or DKIM (the envelope-from domain, or the DKIM d= domain) matches the domain in the visible From header, under either relaxed or strict alignment rules. An alias that passes SPF or DKIM against the wrong domain, or against no domain at all, fails DMARC alignment even if the underlying check technically passed for some other domain.

A real trace of the failure

Authentication-Results: mx.google.com;
  dkim=none (message not signed);
  spf=fail (google.com: domain of transmit-relay.example.net does not
    designate 203.0.113.9 as permitted sender) smtp.mailfrom=sales@example.com;
  dmarc=fail (p=REJECT) header.from=example.com

Here, sales@example.com is an alias configured on a mailbox, but the message was actually relayed through a third-party platform (transmit-relay.example.net) whose sending IP (203.0.113.9) was never added to example.com's SPF record, and which did not sign with DKIM for example.com at all. The visible From header says the trusted domain; the actual authenticated identity is nothing. With DMARC at p=reject, this message does not reach the inbox - it is rejected outright.

This is the pattern worth checking first whenever an alias "used to work" and then suddenly started bouncing: something about the sending path changed - a new relay, a migrated ESP, a platform update - while the domain's SPF and DKIM configuration stayed pointed at the old path.

Why this is easy to miss until enforcement is turned on

With DMARC at p=none (monitoring only), this exact failure still happens on every message, but nothing visible changes - the mail is still delivered, and the authentication failure only shows up in aggregate DMARC reports if you are actually reading them. The moment DMARC moves to p=quarantine or p=reject, the same misconfigured alias traffic starts failing outright, which is why alias-related breakage so often appears to coincide with "turning on DMARC" when the actual cause predates it.

Fixing it

1. Identify every platform or relay that sends mail using an alias of your domain.
2. For each one, add its sending IP range (or the relevant SPF include) to the domain's SPF record.
3. Configure DKIM signing for that platform under your domain, with its own selector if the platform supports custom DKIM (most reputable ESPs and relays do).
4. Confirm the DKIM d= domain and the visible From header domain match under your DMARC alignment mode (relaxed allows subdomain variation; strict requires an exact match).
5. Re-check with a live message and read the Authentication-Results header directly rather than trusting a platform's own "authenticated" indicator in its UI.

What not to do

Do not assume an alias is "covered" because the underlying mailbox has good SPF/DKIM - the alias's actual sending path is what gets checked, not the mailbox it is nominally attached to. Do not leave DMARC at p=none indefinitely to avoid dealing with this - that just delays discovery, it does not prevent the underlying misconfiguration. And do not add a blanket +all or overly permissive SPF mechanism to make alias traffic pass "for now" - that defeats SPF's purpose for the entire domain, not just the alias.

Where MailPilot fits

MailPilot checks SPF, DKIM and DMARC alignment on the sending domain directly, which surfaces exactly this class of mismatch - an alias or relay sending outside the domain's registered authentication - before DMARC enforcement turns a quiet reporting gap into outright message rejection.