Arlo SPF, DKIM and DMARC setup, step by step

On this page: Sending scope · SPF · DKIM · DMARC · Verification · Troubleshooting · FAQs

To authenticate email sent by Arlo Training Management Software, add include:_spf.arlo.co to the appropriate existing SPF policy and arrange DKIM with Arlo Support. Publish the CNAME records Arlo generates, then ask Support to verify and finalize the setup. Check a delivered course email for DMARC alignment before treating the work as complete. Arlo authentication instructions

This guide covers Arlo's training and event platform, not Arlo security cameras. It addresses platform-generated customer communications, not every message an employee sends. No customer account, DNS record or delivered message was tested or changed.

Identify the exact sender before editing DNS

Start with the communications that matter operationally: registration confirmations, course instructions, order messages and reminders. For each route, collect the visible From address, Reply-To, Return-Path and a recent raw message. A local email-client message is not a substitute for a platform-generated course email when checking authentication.

Arlo's default communication details are under Settings → Platform setup → Key settings → Communication Details. Those details are used for future templates. On multi-region platforms, sender details come from each region's Regional Key Settings. Review the relevant regions and existing templates rather than assuming one changed default covers everything. Arlo key settings

Before you begin, identify:

• The person authorized to edit the domain's authoritative DNS zone.
• Every domain and subdomain actually used in From addresses.
• Existing SPF policies, DKIM selectors and DMARC policies, including parent-domain policy.
• Other applications already using SendGrid or the proposed DNS names.
• A controlled external mailbox for later validation without involving registrants.

Export the current DNS zone and keep a record of old values and TTLs. Do not alter MX records for corporate inboxes merely because a sending application is being authenticated.

Employee mail sent through Microsoft 365 is a separate sending route; use the Microsoft 365 authentication guide for that route rather than assuming these application records configure it.

Add Arlo's SPF authorization safely

The documented mechanism is:

include:_spf.arlo.co

Keep the underscore. Arlo says to insert the mechanism before the terminal all in an existing policy. Arlo SPF setup

SPF normally checks the SMTP MAIL FROM domain, commonly reflected in Return-Path, rather than the visible From address. An empty reverse path uses the HELO identity for SPF. A parent-domain SPF record does not automatically apply to a subdomain. Confirm the actual envelope domain with message evidence and Support; a root-domain include is not proof of SPF alignment for every Arlo route. SPF identities and record selection

For example, if example.com already has a reviewed policy authorizing an active corporate mail service, retain that authorization and add Arlo within the same policy. The following is an illustrative merge, not a record to publish unchanged:

Before: v=spf1 include:spf.existing-sender.example -all
After: v=spf1 include:spf.existing-sender.example include:_spf.arlo.co -all

Replace the illustrative existing-sender mechanism with your actual current policy. Preserve its intended terminal qualifier. Do not add a second TXT record beginning v=spf1, concatenate two complete policies, or delete unrelated TXT records. If an existing record uses redirect=, have the administrator review its evaluation before applying a simple merge recipe.

If the existing SPF policy uses redirect=, reconcile its authorizations with the DNS owner before changing it. An all mechanism makes redirect ineffective regardless of their order; do not append all as an automatic merge step. SPF qualifiers express authentication results, not a guaranteed receiver delivery or rejection decision. SPF all and redirect processing.

SPF allows at most 10 evaluated DNS-query-causing terms across mechanisms and nested policies. include, a, mx, exists, ptr and redirect can consume that budget. Count evaluation across the whole policy rather than counting visible includes. Do not replace a managed include with a snapshot of current IP addresses simply to make a checker pass. SPF DNS-processing limits

What if the domain has no SPF record?

Do not create an Arlo-only policy until you have inventoried every sender using that envelope domain. Publishing a restrictive policy can affect legitimate mail that was previously unauthenticated. Plan the first policy with the mail administrator, validate its sender coverage and separately complete DKIM. No SPF record is not evidence of successful authentication.

Complete the support-assisted DKIM workflow

Arlo documents a three-party handoff: Support generates records, your DNS administrator publishes them, and Support verifies and finalizes DKIM. Contact support@arlo.co or your Customer Success Manager with the sending address, technical contact and DNS host. Tell them about existing SendGrid CNAMEs; Arlo can use custom identifiers to avoid collisions. Arlo DKIM workflow

Use this implementation checklist:

1. Collect the issued record set. Save each owner, type and target together. Confirm which From domains and Arlo platform the request covers. Do not copy selectors or targets from another organization's setup.
2. Inspect existing owners. If a requested name already has a TXT record or a CNAME for another sender, stop and resolve the conflict with Support. Replacing it can break the other service.
3. Publish the exact CNAMEs. In a DNS editor that appends example.com, an issued full name such as selector._domainkey.example.com may need only selector._domainkey in the host field. The actual selector must come from Arlo.
4. Check DNS before handing back. Confirm the fully qualified names resolve to the issued targets. Preserve their target spelling and avoid a doubled zone suffix.
5. Obtain completion confirmation. Tell Support the records are published and ask them to confirm finalization for the intended domains. A saved DNS entry alone is not evidence that signing has begun.

If you use Cloudflare, keep authentication CNAMEs DNS only, not proxied. Do not flatten the verification CNAMEs: the provider needs to retrieve the aliases, and flattening can hide them. Limit this change to the authentication records rather than turning off unrelated website protection. Cloudflare proxy guidance, CNAME flattening and verification

Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.

A CNAME owner generally cannot coexist with other record data. Keep existing selectors for other sending systems and do not replace a requested CNAME with an unrelated generated DKIM key. The public DNS record must lead to the key matching the sending platform's private key. DNS CNAME rules, DKIM key discovery

For an issued full owner SELECTOR._domainkey.training.example.com, use SELECTOR._domainkey.training in an appending example.com zone, or SELECTOR._domainkey in a separately delegated training.example.com zone. If _domainkey.training.example.com is itself delegated, publish SELECTOR with that authority. Use Arlo's actual selector, preserve the delegation and do not change nameservers, DNSSEC or forwarding to expose a parent-zone record. DNS zone boundaries.

Arlo allows 1–24 hours for SPF changes to affect delivery, depending on TTL. It says DKIM DNS propagation can take up to 24 hours and Support verification a day or two. Check authoritative publication immediately; waiting is appropriate for cached correct records, not an incorrect owner. Arlo timing guidance

Arlo uses SendGrid for this platform mail. That does not mean you should authenticate it in a separate SendGrid account or borrow another application's records. The records issued for this Arlo setup are authoritative. Arlo sending infrastructure

Preserve DMARC while checking alignment

DMARC passes when at least one of these conditions is satisfied:

• SPF passes and the authenticated MAIL FROM domain aligns with the visible From domain.
• DKIM passes and its signing domain, the d= value, aligns with the visible From domain.

Relaxed alignment accepts domains sharing the organizational domain; strict alignment requires exact equality. A valid signature belonging only to an unrelated provider domain does not authenticate your From domain for DMARC. Current DMARC is specified in RFC 9989, which supersedes RFC 7489. The old pct tag is obsolete; do not depend on it for a new rollout. Current DMARC specification

Retain an established quarantine or reject policy and its alignment settings while repairing the sender. Do not weaken a whole domain's protection to accommodate one unverified course-email route. For a domain with no applicable established policy, monitoring can be the first step after a sender inventory and the domain owner's approval of a monitored rollout. Check inherited policy before adding a child-domain record.

This is a first-time monitoring template only, not a replacement for an existing policy:

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and reporting mailbox. Publish one DMARC policy at the intended owner. Within an example.com zone, the relative host is usually _dmarc; for training.example.com, the full owner is _dmarc.training.example.com. Use an approved report destination. Aggregate reporting and authorization

For From training.example.com, the relative policy owner is _dmarc.training in the parent example.com zone, or _dmarc in a separately delegated training.example.com zone. Full-name fields require _dmarc.training.example.com. Preserve existing delegation and applicable inherited protection.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.

Aggregate reports help reveal legitimate sending paths missed by a single test. Failure reporting can disclose message details, so do not enable it without a privacy review. DMARC failure-report privacy

Validate DNS, activation and delivered course mail

These commands are read-only patterns. Replace all example names, including the selector and authoritative server, with your actual values:

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Use the observed MAIL FROM domain for the SPF query. Query every CNAME Arlo issued, not just one convenient selector. The CNAME answer should match the issued target; the DKIM TXT lookup through that target should retrieve the public key. Compare authoritative DNS with a recursive resolver. Cached values can persist for their previous TTL, but a wrong owner or wrong nameserver delegation will not fix itself by waiting.

Once Support confirms completion, send a controlled message through the actual Arlo workflow. Inspect the receiving mailbox's trusted Authentication-Results, along with From, Return-Path and DKIM-Signature. Ignore authentication headers that an untrusted sender could have supplied. Authentication-Results trust boundary

Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.

Record the result against each sending domain and region:

For a custom-DKIM setup, an SPF-only DMARC pass does not complete acceptance: verify that the intended branded DKIM signature itself passes and aligns. Also investigate an actual SPF failure even when aligned DKIM makes DMARC pass.

Test representative automated emails separately. A result for one region, template or domain does not certify the others. Authentication does not guarantee inbox placement: reputation, recipient filtering and message content remain relevant.

Troubleshoot Arlo authentication failures

CNAME owner already exists: identify its current service owner and ask Arlo for different identifiers. Never delete another application's SendGrid record to force this setup through.

Records resolve but DKIM is absent: confirm Support finalized the correct domain, then compare the test's From address and sending path with the request. A regional setting or older template may be using another identity.

SPF passes but DMARC fails: compare smtp.mailfrom with the visible From domain. Then check the DKIM result and d= domain. An SPF pass for unrelated infrastructure is not aligned authentication.

SPF fails despite an aligned DKIM pass: check the evaluated envelope domain and sending IP against its policy. A fail or softfail can indicate a missing authorization or an unexpected relay; permerror points to duplicate policies, syntax or lookup-limit problems; temperror calls for DNS availability checks and a retest. Do not authorize an unrelated IP merely because it appeared in a forwarded message.

Only one region fails: inspect that region's key settings and the exact message template. The default displayed elsewhere in the platform may not be the source of this message's identity.

The DNS editor rejects the record: check for a conflicting owner, a duplicated domain suffix or a target entered as the wrong record type. Keep the existing record until its purpose is known.

Mail still goes to spam after authentication passes: collect the exact recipient-side result or bounce, timestamp, message ID and sending route. Share only the necessary evidence with Support, excluding participant details and message content that are not needed for diagnosis.