AODocs SPF, DKIM and DMARC setup, step by step

AODocs SPF and DKIM setup starts with identifying the service that actually sends your notifications. Do not add an invented AODocs SPF include or reuse somebody else's DKIM key. A branded sender is an integration task: authenticate the approved sending domain at the email provider, complete the AODocs configuration, then verify a real notification at its destination.

This guide covers existing AODocs Document Management Platform notifications. It does not configure Google Drive sharing invitations, ordinary employee mailbox email, or a new email-provider subscription. Those are different sending routes. AODocs states that its notifications use SPF, DKIM and DMARC; that statement is not proof that a particular customer-domain integration is configured correctly. See AODocs' authentication explanation.

Identify the notification before changing DNS

AODocs documents default notification addresses under noreply.aodocs.com. Its notification catalogue distinguishes workflow, document-sharing and other events. Use the actual message type when planning a test; a successful unrelated email says nothing about this route. See the notification catalogue.

Record the desired visible From address, the approved reply destination, the AODocs instance and the libraries affected. Preserve a before-change sample and the existing settings. Avoid a domain-wide change when the approved scope is one library. Agree on who can authorize DNS edits, integration credentials and the resulting notifications. A configuration tutorial is not permission to send documents to new recipients.

For instance selection, AODocs documents US, EU and dedicated installations. Use the environment your organization already operates, not whichever API link opens first. Do not move data between regions to troubleshoot email. See AODocs instances.

Configure the AODocs integration in the documented order

The official custom-sender procedure specifies:

1. Application Platform licensing and an already verified, authenticated domain at Mailjet, Mailgun or SendGrid.
2. Support configuration first, using the sender domain, provider, address/name, optional reply address/name, provider API key and, for Mailjet, secret key.
3. A super administrator uses domain.configuration.set for domain scope; a library administrator uses library.configuration.set with the correct library ID for library scope. Choose the official US/EU link or obtain the dedicated-instance URL.
4. First call: put emailSender.provider.name in flagName and {"configurationFlagValue":"MAILJET"} in Request body, substituting MAILGUN or SENDGRID when applicable. Authorize and execute; inspect the response before proceeding. Second call: put emailSender.noreplyAddress.domain in flagName and the approved domain string, not an email address, in the Request body's configurationFlagValue. Execute and inspect again. For library scope, retain/re-enter the SAME approved libId in both calls; never copy a screenshot ID.

Library configuration overrides domain configuration. This is API-only, not an administration-interface switch. AODocs says the explorer's deprecation notice does not deprecate its API. The linked existing-flag inspection article required sign-in during this review: obtain an authorized snapshot from your administrator/support rather than guessing current values.

Before execution, have the administrator review both calls together against the approved scope. A successful first call does not establish that the second succeeded. Stop on an error rather than continuing with a partially configured route.

Treat support's credential requirement as a security decision, not an invitation to paste secrets into ordinary email. The owner should approve the exact integration access and use a verified secure transfer method agreed with support. Do not put API keys in DNS, screenshots, article examples, public tickets or a shared change log. If a key was exposed, follow the provider's approved rotation process. Do not disable authentication or bypass a browser security warning because a documentation screenshot mentions deprecation.

Authenticate the selected sending provider

Use only the branch for the provider actually connected to this AODocs instance and scope. Do not publish all three providers' records. The account generating the DNS packet must be the account used by the integration; a green status in another account is not enough.

Mailjet

Open the domain's SPF/DKIM Authentication settings and obtain its full DKIM TXT value. Mailjet publishes include:spf.mailjet.com as its SPF authorization, but an existing policy must be carefully merged, not overwritten. Validate domain ownership separately from SPF/DKIM authentication. Check the selected domain's authentication status after publishing. Never use the shortened public-key example from documentation. See Mailjet's domain-authentication instructions.

Mailgun

Obtain the domain's current records from its control panel or authorized API. Mailgun publishes include:mailgun.org for SPF and shows the relevant DKIM record under Domain Verification & DNS. Use Verify DNS settings in Domain Settings after publishing. Its documentation distinguishes tracking CNAMEs and MX records for receiving/routing mail; these are not permission to redirect your existing inbox. Not every historical or rotated DKIM key must show verified, but the key required by the active configuration must work. See Mailgun domain verification.

SendGrid

Use the appropriate account's Sender Authentication domain workflow. The Use automated security setting controls how SendGrid manages SPF/DKIM; preserve the approved mode and use the complete account-generated packet. Publish the records and return to Verify. Do not hardcode a universal number of records or infer tenant targets from sample screenshots. Before accepting a generated DMARC entry, compare it with your existing policy. Region pinning, custom return paths and selector changes are separate decisions, not automatic troubleshooting steps. See SendGrid domain authentication.

If support's integration packet and the provider dashboard disagree about the account, sender domain or record type, stop and reconcile them. Do not assemble a hybrid configuration from two different routes.

Publish records without breaking another sender

At the authoritative DNS host, compare every proposed owner, type and value with what exists now. Save a rollback copy. A registrar is not necessarily the DNS host. Check whether the editor appends your zone name so that a hostname is not accidentally doubled. A DKIM TXT value must remain complete; a CNAME value is a hostname, not a URL or public key. Never overwrite an existing selector without confirming ownership and the approved rotation plan.

Map the full DNS owner to the authoritative zone

These are illustrative names, not issued AODocs records. If the full DKIM owner is selector._domainkey.mail.example.com, its relative name in the example.com zone is selector._domainkey.mail. In a separately delegated mail.example.com zone, it is selector._domainkey. If _domainkey.mail.example.com itself is delegated, the owner belongs in that delegated zone as selector. Use the actual issued selector and authoritative zone, and preserve the existing NS delegation. Never delete delegation records to make a different editor accept a name.

Likewise, _dmarc.mail.example.com is relative _dmarc.mail in the parent zone but _dmarc in a delegated mail.example.com zone. It is not _dmarc.example.com; those policy owners have different scope. Confirm whether an applicable inherited policy already governs the sender before introducing a child policy.

For an existing selector collision, use the complete owner name rather than just the selector label. See EmailAuth's guide to separating DKIM selectors safely.

SPF evaluates SMTP MAIL FROM, or HELO where applicable, rather than automatically evaluating the visible From address. Publish one SPF TXT policy per evaluated owner. Preserve existing authorizations and qualifiers. The limit is ten evaluated DNS-dependent terms, including nested processing, not ten visible includes. An all mechanism causes redirect to be ignored. Neither -all nor ~all guarantees a receiver's delivery decision. See RFC 7208.

Do not add TXT data at a CNAME owner. For required authentication CNAMEs, preserve DNS-only operation and a literal CNAME answer when the sender's verifier requires it. Cloudflare can flatten records through per-record or whole-zone settings, and applies special behavior at the apex and for same-zone targets. Turn off the relevant per-record Flatten control where available and ensure applicable zone settings do not hide the issued aliases. If mandatory behavior prevents the required answer, coordinate a supported layout rather than deleting shared records or changing global settings blindly. See Cloudflare's current flattening controls.

Any A, MX, delegation or forwarding change must match an independently approved routing plan. An account-generated packet can contain changes with consequences beyond authentication. Copying it correctly is not the same as approving those consequences.

Preserve DMARC protection

Keep an existing direct or applicable inherited policy intact. Do not replace enforcement with p=none merely to make the integration appear successful. If there is no applicable policy and the domain owner approves a first monitoring policy, publish a TXT record at _dmarc beneath the intended policy domain with v=DMARC1; p=none;. Do not add a second DMARC record.

DMARC requires at least one passing, aligned authentication path. Evaluate DKIM alignment under adkim and SPF alignment under aspf separately. Relaxed alignment allows the same Organizational Domain; strict alignment requires an exact match to the visible From domain. A child MAIL FROM domain may align relaxed but fail strict aspf against a parent From domain; do not infer strict SPF alignment from a provider's bounce-domain name. For a newly branded DKIM setup, require the intended signature to pass and align with the visible From, not just a DMARC pass obtained through SPF. See RFC 9989.

Add reporting destinations only with approval. A destination outside the policy domain's Organizational Domain requires the receiving reporter to check external-report DNS authorization; a destination inside the same Organizational Domain is excepted. That protocol check does not authorize sharing report data. See RFC 9990, section 4.

Verify an actual AODocs notification

Keep four checkpoints separate: DNS answers, sending-provider verification, AODocs integration configuration and delivered-message authentication. Only the last proves what happened to that particular message.

Arrange a controlled notification to an authorized test recipient using the intended library and message type. Do not trigger real approval requests, production document sharing or broad workflow changes as a test. Record the time and relevant scope without including confidential document contents in the troubleshooting record.

Read results produced inside the actual receiving service's trusted processing boundary. Ask its administrator which authentication results it generates and how it removes or distinguishes externally supplied results. A familiar authserv-id, header position or a copied Authentication-Results field is not proof of trust. Ignore attacker-supplied fields. See RFC 8601.

Confirm the intended visible From, the selected provider's DKIM signature, its signing domain and selector, aligned dkim=pass, and the trusted receiver's dmarc=pass. Inspect SPF independently using the reported envelope identity. Investigate fail, temporary lookup errors and permanent policy errors separately, even if DKIM allows DMARC to pass. A provider-domain rewrite is not successful authentication of your intended brand.

Troubleshooting and rollback

• DNS verifies, but the wrong sender appears: compare the actual message and intended integration scope before editing DNS again. Preserve the API responses and ask the administrator to resolve configuration precedence.
• Only some notifications work: compare the affected libraries, message types and actual provider accounts. Do not assume one successful test covers every event.
• DKIM is absent or fails: confirm the integration uses the account whose DNS records were published. Check the exact active selector and key. DNS publication alone cannot force an unrelated sender to sign.
• DMARC fails despite DKIM pass: compare the signing domain with the visible From under the current alignment mode. Do not weaken the policy as the first remedy.
• Messages authenticate but land in spam: investigate recipient policy, content, reputation and sending behavior. Authentication is not an inbox guarantee.

If acceptance checks fail, pause expansion. Restore only the approved changed configuration using the saved snapshot and support's rollback procedure. Do not delete keys while legitimate messages may still need verification, remove another sender's authorization, or rotate integration secrets without coordination. Repeat the controlled test after the correction.