Domain Alias Email Misconfigurations: 5 Exact Fixes

You set up domain alias email — sales@yourcompany.com routing to your inbox, support@ pointing to the help desk. Looked fine in the admin panel. Then the leads dried up, a client said their email bounced, and you realized you've been replying from your personal address for three weeks.

When domain alias email breaks, it's rarely a typo. It's a collision between legacy routing logic and modern authentication — SPF, DKIM, DMARC — that nobody warned you about when you configured the alias.

If you're seeing 550 5.7.520, 554 5.4.14, or mail is vanishing with a polite 250 OK from your server, stop guessing. This guide covers the five most common domain alias email misconfigurations with their exact error codes and the fixes that actually work.

If you need the foundational architecture first — what makes an alias different from a mailbox — read domain email alias vs. mailbox before continuing.

Is Your Domain Alias Email Actually Broken? Start Here

A domain alias email failure almost always matches one of five patterns. Each has a distinct symptom and error code. Match yours to the right row before touching DNS, routing rules, or admin policies — the error code tells you exactly where to look.

Why Domain Alias Email Breaks: The Two "From" Problem

Every email has two sender addresses, and a domain alias email breaks when these two diverge. The Envelope Sender (RFC 5321 MAIL FROM) is used by servers for bounce routing — this is what SPF checks. The Header Sender (RFC 5322 From:) is what your recipient sees in Gmail or Outlook — this is what DMARC validates against.

When mail routes internally — sales@ to bob@ on the same server — both addresses stay aligned and authentication passes. The moment you forward externally, the receiving server sees a connection from your forwarding server's IP. It checks SPF for the original sender's domain. Your server isn't listed. SPF fails. If the original sender has p=reject in their DMARC record, the message is dropped — no bounce, no notification, just silence on your end.

Misconfiguration 1: External Forwarding Without SRS

Forwarding a domain alias email to a Gmail, Yahoo, or personal Outlook.com address breaks SPF for any sender with a strict DMARC policy. This is the most common domain alias email failure in 2025–2026, and it's getting worse as more organizations tighten DMARC to p=reject.

The scenario: customer alice@bank.com emails contact@yourdomain.com. Your server forwards it to you@gmail.com. Gmail checks the SPF record for bank.com. Your forwarding server's IP isn't listed in bank.com's SPF. SPF fails. Bank has p=reject. Message dropped. Your server already returned 250 OK, so you get no bounce.

The fix: Sender Rewriting Scheme (SRS). SRS rewrites the Envelope Sender to your domain before delivery:

Original envelope: alice@bank.com
After SRS rewrite: SRS0=hash=TT=bank.com=alice@yourdomain.com

Now Gmail checks SPF against yourdomain.com. Your server is authorized. SPF passes. SRS runs at the server level — your hosting provider or mail server admin enables it. Postfix and Exim both have SRS modules available.

Important caveat: SRS fixes SPF alignment but doesn't automatically fix DMARC if the original sender's From domain differs from your signing domain. For complete DMARC alignment on forwarded mail, you also need ARC (Authenticated Received Chain) or outbound DKIM signing on your domain.

The cleaner fix: stop forwarding to external providers entirely. Use a real IMAP mailbox on your domain and access it with a mobile client. External forwarding is a 2012 pattern that modern email authentication has largely broken.

Misconfiguration 2: Microsoft 365 Blocking External Forwarding

If your domain alias email forwards externally and senders are hitting 550 5.7.520 Access denied, Microsoft made that policy decision for you. The default Outbound Spam Filter in Exchange Online is set to "Automatic — System-controlled," which now resolves to Block for automatic external forwarding. Microsoft tightened this deliberately to prevent data exfiltration.

Admin portal fix:

1. Go to the Microsoft 365 Defender portal
2. Navigate to: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Edit Anti-spam outbound policy (Default)
4. Set "Automatic forwarding rules" to On — Forwarding is enabled

If you want forwarding enabled for specific users only — the more defensible approach — create a custom outbound policy scoped to those accounts instead of changing the org-wide default.

PowerShell alternative:

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Misconfiguration 3: The Routing Loop

Most domain alias email routing loops produce 554 5.4.14 Hop Count Exceeded. The message bounces between two addresses until the server hits its hop limit — usually 15–20 hops — then gives up. The original sender gets a bounce; you get nothing.

The loop almost always traces to a forgotten inbox rule on the destination mailbox:

Server alias: info@ → admin@
Mailbox rule on admin@: forward everything to info@ for archiving
Result: infinite loop until hop count exceeded

It's almost always in the last place you look — a vacation responder from two years ago, an "archive all to info@" rule someone set and forgot. Audit both server-side alias rules and client-side inbox rules. In Exchange, check Transport Rules in the admin center. In Google Workspace, check "Filters and Blocked Addresses" on each affected account.

Structural fix: ensure your mail server expands aliases before applying user-level inbox rules. If expansion happens after, a "redirect" (which preserves the original recipient address) can cause the alias to trigger again. Use a plain "deliver to" route for alias targets, not a redirect.

Misconfiguration 4: The "Send As" Identity Leak

A domain alias email that only receives mail is half-broken. If you reply to a message sent to sales@yourcompany.com and the recipient sees bob.smith@yourcompany.com in the From field, you've defeated the whole point of the alias. This identity leak happens silently — you don't see it from your end.

Google Workspace fix:

1. Open User Settings → Accounts → "Send mail as"
2. Add the alias address
3. Critical: uncheck "Treat as an alias." If that box stays checked, Google may expose your primary address in headers or the Reply-To field.

Microsoft 365 fix:

By default, M365 shows "Bob on behalf of Sales" when sending from an alias. To remove the "on behalf of" indicator:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

This applies to Exchange Online only — not on-premises Exchange.

Misconfiguration 5: Catch-All Collision

A catch-all (*@domain.com) is a wildcard that captures any unmatched address. If your server evaluates the wildcard before specific alias rules, it can silently swallow traffic meant for a dedicated alias — routing it to the wrong inbox with no error and no trace.

In Postfix, virtual_alias_maps processes top-to-bottom. Explicit aliases must come before the wildcard:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

The wildcard goes last, always. The same applies to MySQL-backed alias tables — specific address rows must have higher match priority than the wildcard row, either via ordering or explicit priority columns depending on your schema.

Advanced Troubleshooting: Read the Raw Headers

When domain alias email fails silently — no bounce, message just vanishes — the answer is in the raw headers of a message that made it to a spam folder. The Authentication-Results header shows exactly what failed and why, more reliably than any bounce message or error log.

In Gmail: open the message → three-dot menu → "Show original." Look for the authentication block:

Broken — SRS missing:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

The smtp.mailfrom is still alice@bank.com. The IP is your forwarding server. SRS didn't run.

Working — SRS active:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

The envelope address has been rewritten. SPF passes against yourdomain.com. DMARC passes on DKIM alignment.

To test whether an alias actually exists on the server, use swaks:

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK means the alias exists and was accepted. 550 User Unknown means it's not in the server's routing table — your alias map has a gap.

Prevention: Flatten the Routing, Eliminate the Hops

The best way to avoid domain alias email misconfigurations is to eliminate the architectural patterns that cause them. Two rules cover most of the failure modes above.

Rule 1: No external forwarding. Business mail stays on the business domain. Use an IMAP client on your phone to access it instead of forwarding to Gmail. External forwarding breaks SPF alignment, routes data through third-party infrastructure, and creates the Send As identity problem. There's no operational upside that outweighs those risks.

Rule 2: Flatten alias chains to one hop.

Every hop is another opportunity for a routing loop, header modification, or authentication failure. One hop maximum.

For temporary or campaign-specific addresses, use plus addressing — bob+newsletter@domain.com — instead of creating a new alias each time. TrekMail, Gmail, and Exchange all support it natively. No configuration required. One caveat: some poorly coded web forms reject the + character, so it's not universally reliable.

For the full breakdown of alias versus forwarding tradeoffs, read email alias forwarding.

When the Problem Is the Pricing Model

Most domain alias email complexity exists because per-user pricing makes dedicated mailboxes expensive. You create aliases to avoid paying for an extra seat — then spend hours debugging SRS headers and PowerShell forwarding policies as the side effect.

TrekMail charges a flat rate per domain, not per mailbox. On the Starter plan ($3.50/month), you can create sales@, support@, and billing@ as real, dedicated IMAP mailboxes — each with its own login, its own storage, and its own native From address. No alias routing. No Send As configuration. No identity leaks.

For agencies: the Pro plan ($10/month) covers 100 domains. Add a client, provision their mailboxes, done — no per-seat math, no license adjustment. If you're migrating existing mail, the built-in IMAP migration tool pulls history from Gmail or cPanel without touching the live environment.

If you're setting up email on a domain for the first time, how to create email with your domain walks through the full process. Or go straight to TrekMail pricing — flat-rate, no per-user fees, 14-day paid-plan trial with credit card required.

Conclusion

Domain alias email breaks in five predictable ways: SPF failure from external forwarding without SRS, Microsoft 365 policy blocks, routing loops from forgotten inbox rules, identity leaks from missing Send As config, and catch-all wildcard collisions. Each failure has a specific error code and a specific fix.

If you're hitting these problems repeatedly, the root cause might not be configuration — it might be that you're engineering workarounds for a per-user pricing model. That's a different fix entirely.

For the broader context on email forwarding architecture and debugging, start with email forwarding setup and fixes.