DMARC for MENA SaaS: test alignment before enforcement

A receipt can pass SPF and DKIM yet fail DMARC. The checks may have authenticated the email provider's domains rather than the domain the customer sees in the From address.

For a MENA SaaS team moving password resets, invoices or account alerts between providers, that distinction belongs in the migration plan. A green DNS dashboard is not enough. Inspect messages received through the actual sending path, then decide whether the domain is ready for enforcement.

This guide proposes an alignment review and release test. It does not claim measured inbox-placement results. Arabic message layout is a separate concern, covered in SultanByte's transactional email rendering guide.

Cover: original SultanByte artwork showing a visible sender domain checked against authenticated sending identities.

Record the identities before changing DNS

Start with a sending inventory. For each application, support tool and campaign platform, record the visible From domain, envelope-sender domain, DKIM signing domain, provider account and operational owner. Include forgotten invoice jobs and emergency notification paths, not only the main application.

Amazon SES's custom MAIL FROM documentation distinguishes the visible From address from the SMTP MAIL FROM address used for bounce handling. SES normally uses a subdomain of amazonses.com for the latter unless a custom domain is configured.

DKIM adds another identity. Its signing domain appears in the signature's d= value; the selector identifies the key used for verification. RFC 6376 defines these fields and the signature-verification process. A valid signature proves something about that signing domain, not automatically about every address printed in the message.

For the review, use one received message per sending path and message type. Record the identities in a small ledger rather than relying on screenshots of provider setup pages. Keep message bodies and reset tokens out of that ledger. The useful evidence is which service sent the message, which identities it used and what the receiving system reported.

Read a pass together with its domain

The current DMARC specification, RFC 9989, was published in May 2026 and obsoletes RFC 7489 and RFC 9091. A DMARC pass requires a successful SPF or DKIM result whose domain aligns with the visible From domain. Strict alignment requires identical domains; relaxed alignment permits a shared Organizational Domain.

Do not implement relaxed alignment by taking the last two labels of a hostname. Use a maintained DMARC evaluator and check which specification it implements. RFC 9989 changes domain discovery to a DNS tree walk, so an older guide is not a complete implementation reference.

Consider an illustrative message with From: receipts@example.com. SPF passes for bounce.example.net, and DKIM passes with d=example.net. Neither domain aligns with example.com. The two successful authentication results do not produce a DMARC pass.

SES's DMARC guide makes the alternative paths explicit: a passing, aligned DKIM signature can satisfy DMARC even if SPF does not; a passing, aligned SPF result can also satisfy it. Configure both mechanisms where supported, but diagnose their results separately.

Original infographic: SultanByte. Illustrative authentication cases based on RFC 9989 (May 2026) and Amazon SES documentation. These are logical examples, not live delivery measurements.

Separate mailbox requirements from protocol logic

A protocol's pass condition is not the whole receiving provider's policy. Google's sender guidelines require SPF or DKIM for all senders to personal Gmail accounts, and SPF, DKIM and DMARC for bulk senders. The bulk requirements permit a DMARC policy of p=none, but still require alignment for direct mail. Marketing and subscribed messages in that category also need one-click unsubscribe and a visible unsubscribe link.

Yahoo's requirements likewise require both SPF and DKIM for bulk senders, a valid DMARC policy of at least p=none, and a DMARC pass. Yahoo also recommends separating bulk or marketing traffic from transactional messages and alerts by IP or DKIM domain.

For the proposed architecture, give transactional and promotional streams distinct operational ownership and monitor them separately. Treat that separation as a control you must verify, not a promise that one stream can never affect another's reputation.

A UAE billing product and a Saudi customer portal should each inventory their actual senders and recipients. Country and interface language are not substitutes for mailbox-provider requirements. Keep any assessment of message content, processing locations and contractual obligations separate from this authentication exercise; an aligned domain does not answer those questions.

Choose the failure behaviour deliberately

SES offers a useful example of a migration trap. Its custom MAIL FROM settings let you choose what happens when the required MX configuration fails: fall back to the default MAIL FROM domain, or reject the send with MailFromDomainNotVerified.

Our recommendation is to document that choice beside the sending identity. If fallback occurs, verify whether the remaining DKIM path still passes and aligns. Do not assume the custom envelope identity is present merely because it was configured earlier.

For a password-reset stream, deliberately refusing to send and continuing through a different authentication path have different customer consequences. Product and operations owners should agree how the application reports a failed send, which alert reaches the on-call engineer and what recovery route remains available. Test that route before changing the policy.

Keep provider-specific DNS instructions scoped to the identity and region actually in use. Avoid copying an MX target from an unrelated tutorial. Also review SPF before adding another service: RFC 7208 limits DNS-querying mechanisms and modifiers to ten during evaluation; exceeding the limit produces permerror. Nested includes count toward the evaluation, so counting only visible include statements is insufficient.

Move to enforcement with evidence from every sender

For an existing domain, AWS recommends a phased DMARC rollout: observe with p=none, resolve legitimate sending gaps, then consider quarantine and reject. Those policies express requested handling for failures; they do not turn unauthenticated messages into authenticated ones.

Assign an owner to every unexplained source in the reports. It may be an unauthorized sender, but it may also be a legitimate service missing from the inventory. Verify the source before authorizing it. Never add a sender simply to make a chart look cleaner.

Require representative billing, support and account-recovery traffic before approving the next stage. A quiet weekend does not exercise a month-end invoice job. Keep the previous DNS configuration and a documented rollback process, including the consequences of cached records.

Do not copy a percentage-based rollout recipe uncritically. RFC 9989 removes the old pct tag. Ask tooling vendors how they handle the revised standard and validate the receiving paths you depend on rather than assuming uniform adoption.

Keep reports and delivery events separate

DMARC aggregate reporting is specified in RFC 9990. Its purpose is domain-level authentication feedback, not a receipt proving that a particular customer's invoice reached an inbox. The specification also discusses third-party report processing and warns that malformed archives or XML can attack a report processor.

For this design, send aggregate reports to a controlled service with an owner, bounded retention and restricted access. If you operate the parser, impose decompression and parsing limits. Treat incoming reports as untrusted data, not instructions to update DNS automatically.

Maintain delivery events separately. SES's notification guidance covers bounces, complaints and delivery notifications, and notes that identity notifications are configured per AWS Region. A secondary sending deployment therefore needs its own notification check.

Use application message IDs to connect a send attempt to provider events without retaining sensitive bodies. Decide how permanent failures suppress further attempts, how transient failures are retried and how support can distinguish a rejected send from an accepted one. Authentication, transport acceptance and inbox placement should remain separate fields in the operational view.

A release test for the actual mail path

Use accounts your team controls and synthetic content. The following are proposed acceptance cases, not claims that a particular provider has passed them:

• Send through every production-capable provider and failover route. Capture the visible From, MAIL FROM and DKIM signing domains from the received message, plus the receiver's SPF, DKIM and DMARC results.

• Exercise the deliberately unaligned example above in an isolated test setup. Confirm the evaluator does not mistake two authentication passes for alignment.

• Test a passing aligned DKIM path when SPF fails, and a passing aligned SPF path when DKIM fails. Keep the provider's broader sending requirements in the review even when the protocol result passes.

• In a disposable test identity, exercise a custom MAIL FROM configuration failure without changing production DNS. Verify the configured fallback or rejection, the application response and the operational alert.

• Inspect delivery events and controlled inboxes independently. Record a forwarding case separately because the intermediary is part of a different delivery path.

When interpreting headers, trust only the receiving system's authentication results within its trust boundary. RFC 8601 explains why an Authentication-Results header from an untrusted source cannot simply be accepted as proof.

For a CTO, the approval artifact should be a sender inventory with observed alignment results and unresolved failures, not a single DNS score. For the engineer making the change, keep one reproducible received-message example for each approved path and repeat it after a provider or identity change.

Enforce only when the legitimate mail streams are accounted for and the recovery plan is usable. Then keep monitoring: the next forgotten integration can introduce a new sending path without anyone touching the main application.