Email aliases and deliverability: what breaks when you send from one

An email alias (sales@example.com forwarding to or sending as a real mailbox) is a routing convenience, not a separate authenticated identity, and that distinction matters the moment you use one as a "From" address for anything beyond casual one-off mail.

How aliases actually work

• Google Workspace / Gmail "Send As": an alias lets a mailbox send with a different From address. Gmail will DKIM-sign as the alias domain only if you have configured a custom "Send mail as" with its own SMTP relay and DKIM key, or if the alias is on the same verified domain and Gmail applies its own domain-wide DKIM. A naive alias setup without checking "Treat as an alias" and the correct DKIM selector can result in mail signed for the wrong domain, breaking DKIM alignment for DMARC purposes.
• Microsoft 365 / Outlook aliases: a proxy address on a mailbox. Outbound mail sent "as" the alias is still delivered through the same mailbox's transport, and DKIM signing follows the primary accepted domain's configuration unless you explicitly add a DKIM selector for the alias domain too.
• Forwarding-only aliases (no send capability, just inbound routing): irrelevant to sending reputation, but relevant to a different failure - a forwarded message can break SPF for the *original* sender if the forwarding server does not rewrite the envelope sender (SRS) or the destination evaluates SPF too strictly on forwarded mail.

The alignment problem in one example

Say marketing@example.com is configured as an alias on a mailbox that is actually ops@example.com, and marketing campaigns are sent "as" the alias.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=ops-selector;
  spf=pass smtp.mailfrom=ops@example.com;
  dmarc=pass (p=REJECT) header.from=example.com

DMARC passes here because both SPF and DKIM are aligned to the same organisational domain (example.com), even though the DKIM selector belongs to the "ops" configuration and the visible From header says "marketing@example.com". DMARC alignment checks the *domain*, not the exact local part, so this actually works - the risk is narrower than people assume, provided the alias is on the same domain and that domain's DKIM/SPF are configured correctly overall.

The real failure mode is when the alias routes through a *different* sending platform than the one SPF and DKIM were set up for - for example, a marketing tool sending "as" sales@example.com through its own infrastructure, while SPF for example.com only authorises the primary mail provider. That produces an SPF fail and, if DKIM is not separately configured for the marketing platform, a DMARC fail too.

Reputation does not transfer to an alias

A mailbox that has been warmed and has a strong sending history carries that reputation on its actual sending infrastructure and authenticated identity - not automatically on every alias that happens to point at it. If you start high-volume sending from a newly created alias through a different path (a new ESP, a different IP range) than the one that built the reputation, you are effectively starting a new sender relationship regardless of how established the underlying mailbox is.

A checklist before sending from an alias

1. Confirm which actual transport/IP range the alias will send through.
2. Confirm SPF for the organisational domain authorises that transport.
3. Confirm DKIM is configured and signing for that transport, with a selector valid for the domain used in the From header.
4. Check DMARC alignment mode (aspf/adkim, relaxed vs strict) - strict alignment requires an exact domain match, not just the same organisational domain.
5. If volume is meaningfully different from what the alias has handled before, treat it as a new sending pattern and ramp rather than switching all traffic at once.

What not to do

Do not assume an alias "inherits" DKIM or SPF just because it forwards to or displays as a trusted mailbox - check the actual signing configuration. Do not route high-volume marketing or notification mail through a personal or support alias without first confirming SPF authorises that specific sending path. And do not ignore SRS (Sender Rewriting Scheme) on forwarding-only aliases if you are the one receiving and then forwarding mail onward - without it you can break SPF for messages that were never yours to begin with.

Where MailPilot fits

MailPilot checks SPF, DKIM and DMARC on the sending domain, which catches exactly this class of problem - a transport or alias that is not covered by the existing authentication setup - before it shows up as a wave of bounces or a reputation drop on a mailbox that otherwise looks fine.