DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

Sending Mail from an Alias in Exchange Online: What Happens to DMARC Alignment When Send-from-Alias Goes GA

By DMARCGuardian Editorial Team ·

Microsoft made Exchange Online's Send-from-Alias feature generally available in October 2026. After nearly five years in preview, mailboxes can now send from any of their proxy SMTP addresses - including addresses that use a different accepted domain than the user's primary SMTP address - without routing through a shared mailbox. The feature is useful and removes a long-running workaround. It also quietly raises the volume of mail whose alignment DMARC has to evaluate, and that is the part to think through first.

If you are about to flip Send-from-Alias on tenant-wide, the question to answer is not "does the feature work." The answer is yes. The question is whether each accepted domain the user might pick as a From: alias already has its own SPF, DKIM, and DMARC configuration, or whether the tenant is about to start producing mail whose alignment fails at the receiver. That is the durable question. The GA date is the trigger; the alignment work is what lasts.

This article walks through what Send-from-Alias changes, what it does not change about DMARC alignment, and the five-point pre-flight checklist to run before you enable it. The same checklist is what you use afterward, when an aggregate report starts showing dmarc=fail rows you did not see before the rollout. DMARCFlow is built to surface exactly this monitoring - per accepted domain, per header.from - and is mentioned in the after-rollout section below.

What Microsoft actually changed

Send-from-Alias used to be a Set-OrganizationConfig flag that sat in preview since January 2022. As of the October 2026 general availability announcement, the flag is GA:


Set-OrganizationConfig -SendFromAliasEnabled $true

When the flag is on, a mailbox owner can use any of their configured proxy addresses as the sender on outgoing mail. The mail goes through the user's mailbox, not through a shared mailbox. That is the practical difference. Before Send-from-Alias, the workaround for "I want to send as a different address from my own tenant" was a shared mailbox with SendAs permission. Useful, but it forced the conversation through a different mailbox, and continuity got ugly when someone left the company and took their mail history with them.

If you want to keep some accepted domains off the alias-sending path, you can still block them per domain:


Set-AcceptedDomain -Identity tenant.onmicrosoft.com -SendingFromDomainDisabled $true

The new capability is real and useful. What it does not do is configure anything for you on the DNS side. That part is still on the admin, and that is where the DMARC alignment risk lives.

Why DMARC alignment is the part that can break

DMARC alignment is checked at the receiver, against the message that arrives - not the message the user composed. Three identities matter. At least one must align with the From: header domain in relaxed or strict mode for the message to pass DMARC:

  • The envelope sender, also called 5321.MailFrom or Return-Path. Set by the server that submits the mail to the next hop, not by the composing user.
  • The From header, the RFC 5322.From the recipient sees in their mail client. DMARC alignment checks against this domain.
  • The DKIM signing domain, the d= tag in the DKIM-Signature header. Set by whichever infrastructure signs the message.

For DMARC pass, the From header's domain must match either the envelope sender's domain (SPF/DMARC alignment) or the DKIM signing domain (DKIM/DMARC alignment). Both checks can be relaxed (organizational domain match) or strict (exact host match). If neither identity aligns, the message fails DMARC regardless of how good SPF and DKIM individually look.

#### Why Exchange Online's outbound path matters for all three

Here is the part that catches admins out. When a user composes a message in Outlook and hits send, Exchange Online takes over the outbound transport. The envelope sender is set by Microsoft on the outbound connector. If the user's primary accepted domain is tailspintoys.com but they pick the alias support@supportdesk.tailspintoys.com as the From: address, the envelope sender may still resolve to a Microsoft-controlled domain like tenant.onmicrosoft.com or to the primary domain, depending on tenant configuration. The DKIM signature is applied based on which DKIM keys Microsoft has enabled and published for the tenant.

If the DKIM key for supportdesk.tailspintoys.com is not published in DNS, Microsoft has no key to sign with, and the message either lacks a DKIM signature entirely or signs with a domain that does not match the From header. The receiver's authentication report then reads something like dkim=none or dkim=pass header.d=tenant.onmicrosoft.com, spf=pass from the M365 outbound pool, and dmarc=fail because no identity aligned with supportdesk.tailspintoys.com. That is the alignment failure pattern that Send-from-Alias introduces when it gets rolled out without the per-domain DNS first.

What to verify before you flip the tenant switch

Run these five checks in order. They cover the configuration that Send-from-Alias depends on but does not configure for you.

#### Inventory which accepted domains should still allow alias sending

Some accepted domains in a tenant are convenient historical artifacts - old brand domains, test domains, default onmicrosoft.com domains. Send-from-Alias will route mail from all of them unless you block per domain. Run:


Get-AcceptedDomain | Format-Table DomainName, SendingFromDomainDisabled

Block any accepted domain you do not want users sending as. This is the only step that limits Send-from-Alias blast radius.

#### Enable DKIM for every alias domain you want users sending as

DKIM is enabled per accepted domain in the Microsoft 365 admin center under Security -> Email authentication -> DKIM. For each accepted domain that should appear in a From: header:

1. Generate the DKIM keys in the admin center (the default selector names are usually selector1 and selector2).
2. Publish both CNAMEs at your DNS provider.
3. Wait for DNS propagation, then return to the admin center and click Enable for that domain.

Until this is done for a specific accepted domain, mail from that domain cannot have a valid DKIM signature. Some mail will still pass DMARC via SPF alignment alone, but only if the SPF record for the alias domain explicitly authorizes the Microsoft 365 outbound IPs.

#### Make sure SPF authorizes Microsoft 365 for the alias domain

The SPF record for an accepted domain should include include:spf.protection.outlook.com if the domain sends mail through Exchange Online. If you have hybrid senders (an on-prem Exchange or a relay in front of M365), include those as well:


v=spf1 include:spf.protection.outlook.com include:spf.contoso.local -all

SPF is easy to get wrong, mostly because of the 10-DNS-lookup limit. If your include chain already pushes close to 10, adding the Microsoft include will push it over and SPF will fail with permerror. Check the lookup count before publishing.

#### Publish DMARC for the alias domain, not just the tenant primary

DMARC records are evaluated per domain. A tenant can have a perfect DMARC record on its primary accepted domain and still send mail from alias domains that have no DMARC record at all, and many receiving servers treat a missing DMARC record the same as p=none for the purposes of policy. If a sender at supportdesk.tailspintoys.com does not publish a DMARC record, the receiver has nothing to enforce on.

Publish at least:


v=DMARC1; p=none; rua=mailto:dmarc-reports@tailspintoys.com; pct=100

on every accepted domain you want users to be able to send from. Tighten the policy to quarantine only after aggregate reports show clean alignment for that domain.

What alias-induced DMARC failure looks like in the aggregate report

After Send-from-Alias goes on, watch your aggregate report (the rua XML or whatever your RUA receiver parses) for this exact fingerprint:



  
    52.100.x.x
    42
  
  
    supportdesk.tailspintoys.com
  
  
    
      tailspintoys.com
      pass
    
    
      tenant.onmicrosoft.com
      pass
    
    
      fail
      
        none

The signature: header.from=, spf=pass from a Microsoft 365 outbound IP, dkim=pass from a different domain (often the tenant default), and dmarc=fail. That combination tells you the alias domain has DKIM either disabled or unsigned, and the message only aligned to SPF because of how the envelope sender is set.

When that pattern shows up in 40% or more of a domain's outgoing volume, the receiving side is going to start rate-limiting or junking those messages quietly, regardless of the strictness of your own DMARC policy. The fix is the same five steps above, applied to the specific accepted domain that is failing.

After rollout: how to catch the failure pattern early

The aggregate reports arrive daily. Reading them by hand across 10 accepted domains is the kind of work that quietly stops happening after week two. Per-domain aggregate monitoring is what keeps the alignment story clean.

DMARCFlow is built for exactly this. It watches the aggregate reports for every accepted domain in a tenant, groups dmarc=fail rows by the header.from domain, and surfaces the moment a domain that previously passed alignment starts failing it. The investigation you would do by hand - which step in the pre-flight list did you skip for that domain - is one row of the dashboard instead of one XML file per sender per day.

The mental model is simple: Send-from-Alias does not change the question, it changes the scale. You used to have to worry about which shared mailboxes were sending as which accepted domains. Now every user in the tenant can pick any of their proxy addresses, and the number of (user, alias, accepted-domain) triples to monitor just multiplied. Per-domain aggregate monitoring is what keeps that from becoming a blind spot, and DMARCFlow is one of the cleaner ways to get there without building a custom RUA parser.

For a tenant with five accepted domains and a heavy Send-from-Alias rollout, the time saving is hours per week, and the time saving is not the point anyway. The point is that the monitoring runs whether or not you remember to log in.

FAQ

What is Send-from-Alias in Exchange Online?

A tenant-level setting that lets a mailbox user send mail using any of their proxy addresses (the alias addresses), without routing through a shared mailbox. It is enabled with Set-OrganizationConfig -SendFromAliasEnabled $true and reached general availability in October 2026.

Does Send-from-Alias break DMARC alignment?

It can, if the alias domain does not have its own DKIM key published and a DMARC record of its own. The message itself is legitimate. The alignment signature at the receiver is what fails.

Do I need DKIM for every accepted domain in Microsoft 365?

Yes, for every accepted domain you want users to send as. DKIM is per domain, not per tenant. The M365 admin center enables and signs per accepted domain.

Does the SPF record for an alias domain cover Microsoft 365's outbound servers?

Only if include:spf.protection.outlook.com is in the SPF record for that domain. The tenant primary's SPF record does not apply to alias domains.

Does a DMARC record apply to every accepted domain in a tenant?

No. DMARC is evaluated per header.from domain. Each accepted domain needs its own DMARC record, otherwise receivers fall back to whatever default behavior they apply for missing DMARC.

How do I detect alias-induced DMARC failures in my aggregate reports?

Look for header.from=, dkim=none or dkim=pass header.d=, and dmarc=fail. That fingerprint points at missing per-domain DKIM or per-domain DMARC.

Should I enable Send-from-Alias tenant-wide at once?

No. Roll it out for a pilot group of users with simple accepted-domain setups first, watch the aggregate reports for the alignment pattern above, then widen the rollout.

Bottom line

Send-from-Alias is a useful GA release. It is also a configuration commitment. Each accepted domain you want users to be able to send from needs its own DKIM key, its own SPF record that authorizes Microsoft 365, and its own DMARC record. Without those three, alias-sent mail will reach receivers but fail alignment checks, and your aggregate reports will say so. Run the five pre-flight checks before the rollout, and read the daily aggregate report with header.from filtering afterward. That combination keeps the feature useful and the alignment clean. The persistent monitoring that ties it together - per-domain failure detection across every accepted domain - is why a tool like DMARCFlow exists, and why it earns its place in the workflow the moment an M365 tenant flips on Send-from-Alias.