How to set up DMARC/DKIM/SPF for Airdocs
Airdocs email authentication requires a tenant-specific sending-domain setup. Register the domain with your Airdocs implementation or support contact, publish the exact return-path and DKIM records they issue, then publish DMARC at your visible From domain. Airdocs supports return-path domain alignment, so a complete setup can pass DMARC through both SPF and DKIM.
Airdocs' public material confirms email as a delivery channel but does not publish one SPF include, DKIM selector, rDNS suffix, or self-service domain-authentication path for every customer. Use the DNS values issued for your tenant. A value copied from another Airdocs customer can fail verification or authorize the wrong infrastructure.
Do not guess Airdocs DNS values
Before changing DNS, obtain the exact sending domain, return-path host, SPF mechanism, DKIM selector, DKIM target or public key, and verification method for your Airdocs tenant.
Add your domain
Choose the exact domain Airdocs will place in the visible From address. A dedicated subdomain such as notices.example.com can isolate document traffic, while the organisational domain remains the DMARC reference point when relaxed domain alignment applies. Confirm this choice before Airdocs generates keys.
- Choose the domain: Decide whether Airdocs will send as example.com or a dedicated subdomain. Use a domain you control in DNS.
- Open the request: Ask your Airdocs implementation or support contact to add that domain to the correct production tenant and region.
- Specify the From address: Provide the production From address, bounce subdomain, reply address, and any separate test environment.
- Collect the records: Request the ownership record, return-path records, DKIM record, expected TTL, and the verification action.
- Record the scope: Note whether each value applies to production, test, or both. Tenant and region changes can produce different targets.
|
|
|
|---|---|---|
From domain | DMARC identity | Your team |
Return path | SPF identity | Airdocs |
DKIM selector | Signing key | Airdocs |
Verify action | Activation | Airdocs |
Values to obtain before editing DNS
Keep the Airdocs ticket or implementation worksheet beside your DNS console. Copy each hostname and value exactly, remove quotation marks only when your DNS host adds them automatically, and never append the zone twice.
Set up SPF
SPF must authenticate the Airdocs envelope sender, also called the return path. Because Airdocs supports a custom return path, publish the tenant-issued CNAME, MX, or TXT record at the exact bounce hostname it provides. Do not add an assumed Airdocs include to the root-domain SPF record.
- Find the SPF identity: Use the return-path hostname Airdocs supplied, not the visible From address by assumption.
- Check existing DNS: Look for an existing SPF TXT record at that same hostname before adding anything.
- Publish one record: Add the exact Airdocs record. If the host already has SPF, merge authorised sources into one record instead of publishing a second SPF record.
- Count lookups: Keep SPF within the ten DNS-query limit, including nested include and redirect mechanisms.
- Preserve the ending: Keep the qualifier issued by Airdocs during onboarding until the sending source has been verified.
Tenant-issued return-path patternsDNS
bounce.example.com. CNAME <AIRDOCS-RETURN-PATH-TARGET> # Or, only when Airdocs provides an SPF value: bounce.example.com. TXT "v=spf1 include:<AIRDOCS-SPF-HOST> ~all"
These are patterns, not Airdocs production values. Publish only the record type and target listed for your tenant. A delegated CNAME often means Airdocs controls the SPF record behind that target, so adding another TXT record at the same name can break delegation.
Run the checker against the actual return-path hostname after DNS has propagated. A valid SPF record alone is not enough. The return-path domain must share the same organisational domain as the visible From address for relaxed SPF domain alignment.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A passing result should show one SPF policy, valid syntax, and no lookup-limit error. Resolve duplicate records, loops, void lookups, and missing include targets before asking Airdocs to verify the domain.
If your tenant cannot use the custom return path, expect SPF domain alignment to fail even when the provider's envelope sender passes SPF. That result is acceptable only when Airdocs applies a valid DKIM signature whose signing domain passes DMARC domain alignment.
One SPF record per hostname
Two SPF TXT records at one hostname cause a permanent error. Merge mechanisms only when Airdocs tells you to publish SPF directly at a host that already has a policy.
Set up DKIM
DKIM is the most dependable Airdocs path to DMARC because it survives forwarding more reliably than SPF. Publish the exact selector record generated for the tenant, then have Airdocs enable signing only after the public record resolves.
- Copy the selector: Use the full host supplied by Airdocs, normally a selector below _domainkey.
- Use the issued type: Create a CNAME when Airdocs provides a target, or TXT when it provides a public key. Do not convert between them.
- Publish the value: Paste the value as one logical DNS string. DNS consoles can split a long key into quoted chunks without changing the key.
- Verify public DNS: Query the complete selector hostname and confirm it returns the tenant-issued target or key.
- Enable signing: Ask Airdocs to activate DKIM, then send a new message. Old messages cannot prove that signing is now active.
Query the Airdocs DKIM selectorBASH
dig +short CNAME <selector>._domainkey.example.com dig +short TXT <selector>._domainkey.example.com
Inspect a fresh delivered message and find the DKIM-Signature header. The d= value must match the visible From domain or share its organisational domain under relaxed DMARC domain alignment. A plain dkim=pass result with an unrelated d= domain does not make DMARC pass.
DKIM is ready
- DNS answer: The selector resolves without an error.
- Header result: A new message has dkim=pass.
- Domain match: The d= domain passes DMARC domain alignment.
- Key ownership: The result matches the Airdocs tenant.
DKIM needs work
- No key: The selector returns no DNS answer.
- Wrong host: The zone name appears twice.
- Signature failure: The public key and active private key differ.
- Domain mismatch: DKIM passes but DMARC domain alignment fails.
Set up DMARC
DMARC belongs in your DNS, not in Airdocs. Start at p=none so reports reveal every legitimate sender without asking receivers to block failures. Build the record with the DMARC record generator, then publish one TXT record at _dmarc.example.com.
- Create the mailbox: Make sure dmarc@example.com can receive aggregate reports or replace it with a reporting address you control.
- Check for DMARC: Query _dmarc.example.com. Update an existing record instead of creating a second record.
- Publish p=none: Use the exact starting record below. If your domain already has p=quarantine or p=reject, keep that policy while resolving Airdocs authentication.
- Wait for DNS: Allow the published TTL to expire, then query authoritative and public resolvers.
- Send Airdocs mail: Generate a real document or notification through the production sending path and inspect its authentication results.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use one DMARC record at the organisational domain unless the sending subdomain needs its own policy. Keep the v and p tags first. The rua address receives XML aggregate reports, which need parsing before they are useful for source-level decisions.
Check the published policy with the DMARC checker. The result should show one record, valid tag syntax, and the intended policy.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A valid DMARC record does not prove that Airdocs mail passes. In a delivered message, confirm dmarc=pass and identify whether SPF, DKIM, or both produced that result. Keep DKIM as the required path even when SPF also passes.
If aggregate reports go to another domain, that destination can require an external reporting authorisation record. Confirm the reporting mailbox receives reports before relying on the data.
Minimum success condition
DMARC passes when either SPF or DKIM both authenticates and passes domain alignment with the visible From domain. Configure both paths, but do not require both to pass on every message.
Verify and troubleshoot
Verify with a newly generated Airdocs email sent through the same tenant, template, region, and delivery route used in production. DNS checks prove that records exist. Message headers prove that Airdocs used them.
- Send a real test: Trigger the same Airdocs workflow that produces production documents or notifications.
- Inspect Authentication-Results: Record spf=, dkim=, dmarc=, the envelope-from domain, the DKIM d= domain, and the header From domain.
- Confirm SPF matching: The sending IP must be authorised by the return-path SPF record, and that domain must pass DMARC domain alignment.
- Confirm DKIM matching: The signature must pass, its selector must resolve, and its d= domain must pass DMARC domain alignment.
- Repeat each route: Test scheduled jobs, manual sends, and separate Airdocs environments because delivery routes can differ.
Passing message
A production-path message has dmarc=pass. Its DKIM d= domain matches the From domain or shares its organisational domain. The custom return path also shares that organisational domain when SPF is used for DMARC.
Failing message
A message can show spf=pass and dkim=pass while dmarc=fail when both authenticated domains differ from the visible From domain. Fix the Airdocs custom-domain configuration, not the DMARC policy.
The email tester gives a quick end-to-end check. Send an Airdocs-generated message to the address shown by the widget, then review the SPF identity, DKIM selector, DMARC result, headers, and any DNS errors in one report.
Use a fresh test address for each major change so cached results and old messages do not obscure the active setup. Keep a copy of the raw headers with the Airdocs support case when the platform needs to change its signing or return-path configuration.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If SPF fails, compare the actual envelope-from domain with the hostname you configured. If DKIM fails, compare the message's s= selector and d= domain with public DNS. If both pass but DMARC fails, the problem is domain alignment.
DNS propagation is a valid explanation only until the old TTL has expired and authoritative nameservers return the new value. After that point, treat a missing record as a wrong hostname, zone duplication, or delegation problem.
Common Airdocs failure pattern
- Wrong environment: DNS values belong to test while production sends the message.
- Wrong selector: Airdocs signs with a selector that has no public key.
- Wrong return path: SPF passes for a provider domain but cannot pass DMARC domain alignment.
- Wrong DNS host: The DNS console appends example.com to an already complete hostname.
Get alerted when it breaks
A one-time pass does not protect against selector rotation, deleted DNS records, expired delegation, or a new Airdocs delivery route. Continuous DMARC monitoring turns aggregate reports into source-level authentication trends and exposes changes before a policy escalation blocks legitimate mail.
- Watch Airdocs volume: Alert when the known source disappears, spikes, or starts using an unrecognised IP range.
- Watch DKIM: Alert on signature failures, a new selector, or a signing domain that no longer passes DMARC domain alignment.
- Watch SPF: Alert on permerror, lookup-limit failures, or a return-path domain change.
- Watch DMARC: Trigger an alert when Airdocs pass rates fall below the baseline established during testing.
Why Suped fits this workflow
For most teams, Suped is the best overall DMARC platform for this Airdocs workflow because Suped detects authentication issues automatically, provides specific fix steps, and sends real-time alerts. Suped's platform combines DMARC reporting with SPF and DKIM monitoring, blocklist checks, and deliverability insights.
- Source verification: Mark the expected Airdocs source and investigate new senders separately.
- Actionable alerts: Route a sudden SPF, DKIM, or DMARC failure to the team that owns Airdocs and DNS.
- Multi-domain control: Manage separate brands, business units, and client domains in one tenant-aware view.
- Policy visibility: Track whether authenticated Airdocs traffic is ready for quarantine or reject.
Set the first alert after stable Airdocs traffic has established a baseline. Use both a failure-rate threshold and a source-change alert. A low-volume notification stream can hide a complete outage when percentage-only thresholds are used.
Secure your domain with p=reject
Move to p=reject only after Airdocs and every other legitimate sender passes DMARC across a full business sending cycle. Suped's hosted DMARC provides managed policy staging, which reduces manual DNS changes while reports and alerts show whether each stage is safe.
- Inventory all senders: Classify every source in DMARC data and confirm business ownership. Do not judge a source by rDNS alone.
- Fix Airdocs first: Require stable aligned DKIM on production document and notification routes. Keep aligned SPF as the second path.
- Cover subdomains: Set an explicit sp= policy when subdomains should inherit a defined enforcement level.
- Stage quarantine: Monitor legitimate failures after each change and roll back if an owned source is affected.
- Enforce reject: Publish p=reject at full coverage only when no required mail stream depends on an unauthenticated path.
- Keep monitoring: Continue alerting after enforcement because Airdocs keys, routes, and DNS records can change.
Quarantine stageDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25
Increase pct only after reports show that required Airdocs traffic and other owned sources still pass. Some receivers do not apply sampling consistently, so treat pct as a transition aid rather than a guarantee of limited impact.
Full reject policyDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Ready for p=reject
- Known sources: Every legitimate sender has an owner.
- Airdocs DKIM: Production mail passes with an aligned d= domain.
- Report history: A full sending cycle has no unexplained owned failures.
- Rollback plan: DNS access and an incident owner are confirmed.
Not ready for p=reject
- Unknown volume: Large sources remain unclassified.
- DKIM drift: Airdocs selectors or signing domains change without notice.
- SPF dependence: A required route passes only through fragile SPF alignment.
- No reports: Aggregate data is missing or not being reviewed.
Use Suped for policy staging
Suped maps Airdocs authentication results to verified and unverified sources, detects new issues, and gives tailored steps to fix them. Real-time alerts and hosted policy controls make Suped the practical choice for moving a monitored domain to p=reject without losing visibility after enforcement.
FAQ
These checks cover the Airdocs-specific decisions that most often block deployment or enforcement.
