Review DMARC Alignment Before a Delegated Sender Goes Live

Start with the recipient-visible identity

A product team may delegate transactional or campaign delivery while continuing to show its own domain in the visible From header. DMARC asks whether an authenticated identifier aligns with that visible domain. Begin with one message stream and one exact From domain. Record who creates content, which platform submits it, which system relays it, the envelope sender, DKIM signing domain and selector, return path, reply path, links, and accountable owner. Different streams can follow different paths even when users see the same brand.

Use distinct synthetic recipients at approved mailbox providers and retain full original headers. A vendor dashboard saying authenticated is not enough: it may refer to the vendor domain rather than the domain being evaluated by DMARC. Parse Authentication-Results from the receiver, the visible From domain, SPF result and evaluated domain, DKIM signatures and validated signing domains, and DMARC result. Remove recipient addresses and message content from durable handoffs unless explicitly required.

Separate SPF success from SPF alignment

SPF authenticates the domain used in the SMTP envelope or HELO evaluation, not the visible From address. A delegated sender can pass SPF for its own bounce domain while failing DMARC alignment with the client domain. Document the actual evaluated identity after forwarding and other routing. If the vendor supports a custom return-path subdomain, verify its DNS, ownership, and alignment rather than assuming a branded label changes protocol behavior.

Review the complete SPF record for the chosen domain, including includes, redirects, mechanisms, lookup behavior, and the ownership of every authorized source. Do not add broad ranges or duplicate records merely to satisfy setup instructions. Publish DNS through the domain owner’s controlled path and query authoritative answers after change. A local recursive resolver’s cached result does not establish what receiving systems can retrieve.

Verify DKIM identity and key custody

DKIM signs selected headers and the message body with a domain in the d= tag and a selector that locates the public key. For each stream, identify who holds the private key, who can rotate it, which headers are signed, canonicalization choices, key size and algorithm supported, selector naming, DNS record ownership, and revocation procedure. Test that the receiver reports a valid signature whose signing domain aligns with the visible From domain under the chosen DMARC mode.

Send variants that exercise template substitution, tracking links, attachments, long lines, non-ASCII content, and any relay that modifies messages. A modification after signing can break body or header verification. Inspect all signatures because an aligned signature can coexist with a failing vendor signature. Do not copy private keys into tickets, repositories, or general test artifacts. The vendor or domain security owner retains key authority; the developer records public evidence and integration behavior.

Choose strict or relaxed alignment intentionally

Relaxed alignment can allow an authenticated subdomain within the same organizational domain to align; strict alignment requires an exact match. Record the organizational-domain interpretation and subdomains involved rather than describing relaxed as less secure in every context. A dedicated sending subdomain can separate reputation and operations, but its visible From choice, DKIM domain, return path, and DMARC inheritance still need a coherent design.

Build a matrix with the production-like valid stream, a vendor-domain return path, an unaligned DKIM signature, a message from an unapproved subdomain, and a spoofed visible From address. For each, record SPF, SPF alignment, DKIM, DKIM alignment, DMARC result, disposition, and receiver. The expected outcomes should follow the written policy. A message reaching the inbox is not equivalent to passing authentication; receiver reputation and filtering decisions add separate variables.

Use aggregate reports to find unknown streams

DMARC aggregate reports can reveal sources using the domain, authentication outcomes, and policy application. Send reports only to approved addresses, validate any external reporting authorization required, and define retention and access. Group by source, header domain, disposition, SPF-aligned result, and DKIM-aligned result. Treat IP attribution carefully because forwarding services, gateways, and shared vendors complicate ownership.

Do not publish report addresses and then ignore their data. Assign each recurring source to an owner and classify it as authorized and aligned, authorized but needing remediation, unknown, forwarded or otherwise explainable, or abusive. Sampling periods should cover routine receipts, scheduled campaigns, billing, support, identity, and rarely used operational notifications. A short quiet window is weak evidence that all legitimate streams are represented.

Stage policy without inventing delivery guarantees

Move from observation toward quarantine or reject only after legitimate streams are inventoried and tested. If pct or subdomain policy is used, state exactly which traffic it changes and how progress will be judged. Monitor aggregate outcomes, vendor events, bounce classifications, support cases, and critical-message canaries. DMARC enforcement tells receivers the domain owner’s requested handling of failing mail; it does not guarantee inbox placement or consistent behavior by every receiver.

Define stop conditions for loss of password resets, receipts, security alerts, or other essential messages. Rollback means a reviewed DNS policy change with expected propagation and report effects, not deleting authentication records at random. Keep last-known-good values, TTL history, approvers, and emergency contact paths. Domain and security owners authorize policy changes; product owners identify critical streams; an offshore developer can prepare the inventory and evidence.

Rehearse rotation and vendor exit

Test a DKIM selector rotation by publishing the incoming public key, confirming receiver validation, switching signing, observing the retry horizon, and retiring the previous selector only when evidence supports removal. Include queued mail signed before the switch. For SPF or return-path changes, account for DNS caching and messages already accepted by the vendor. Record times in UTC and retain authoritative DNS answers.

Write the vendor-exit path while the integration is healthy. Remove sending authority, revoke or destroy private keys under the owner’s process, retire DNS records after safe overlap, preserve required reports, and verify that an old account cannot send aligned mail. If the same subdomain serves several vendors, separation may be needed before one can be removed safely. The exit record is part of delegated access, not optional procurement paperwork.

Hand off evidence by stream

The review packet includes message-stream inventory, visible From domains, envelope domains, DKIM domains and selectors, DNS records, authoritative query evidence, original-header extracts, receiver matrix, alignment mode, report analysis, unknown-source decisions, rollout stages, critical canaries, stop conditions, rotation, vendor exit, limitations, and named owners. It distinguishes authentication results from delivery outcomes and keeps secrets out of shared artifacts.

Acceptance requires at least one aligned authentication path for every approved stream, receiver-observed DMARC success, understood failures, bounded reporting, and an owner-approved policy stage. Unexplained sources or critical unaligned mail block enforcement. Developer Offshore can staff DNS review, test automation, header analysis, and documentation while the client retains domain control, vendor authority, security judgment, and the release decision.

Questions about assessing Philippine developers