[ Email sender guides ]

NationBuilder SPF, DKIM and DMARC setup, step by step

By the EmailAuth research team · 9 min read

On this page

To authenticate NationBuilder broadcaster email while keeping your existing DNS host, add your domain in NationBuilder, publish the unique authentication CNAME records it generates, verify them, and attach an existing custom-domain mailbox to the broadcaster. Do not guess a universal NationBuilder SPF include or DKIM selector. The current documented workflow is account-generated, not a fixed record recipe. NationBuilder authentication instructions.

Scope: native outbound broadcaster email with self-managed DNS and a mailbox hosted elsewhere. This does not migrate your website, nameservers, inbound email or mailbox hosting. NationBuilder-managed DNS is a different route and is not configured here.

On this page

Prepare the domain and mailbox

Use an organization-owned domain, permission to manage its DNS, and access to the relevant NationBuilder domain and communication settings. The reviewed documentation does not establish a universal plan entitlement or role name; if the controls are unavailable, have the account administrator confirm access instead of changing plans or accounts.

Create the actual mailbox with your existing mail provider before attaching it to a broadcaster. A broadcaster is not a substitute for that mailbox. NationBuilder's instructions exclude AOL, Yahoo and Gmail addresses from broadcaster attachment; use your authorized custom-domain address. Broadcaster mailbox requirements.

Record your intended From address, current DNS host and existing authentication records. Keep normal mailbox MX records intact. Existing Google Workspace or Microsoft 365 DKIM does not automatically authenticate messages sent by NationBuilder.

Get the correct NationBuilder records

  1. Open Settings > Domains > New domain and enter your root domain, without www or another subdomain prefix. This documented onboarding path does not establish support for a child sending domain; obtain separate provider confirmation if that is your requirement.
  2. For this self-managed route, leave “NationBuilder should manage this domain” unchecked. Do not switch nameservers or hand over DNS as an authentication shortcut.
  3. Add the domain without moving a website: NationBuilder expressly allows a domain to be connected for email without attaching a site.
  4. In Settings > Domains, hover over the domain and choose Edit. Its Settings section provides the unique CNAME authentication records. Copy the current records for this specific domain, not an example from another nation.

These email-specific steps come from NationBuilder's self-managed DNS guide. Its website, redirect, SSL and CAA sections address separate website tasks. Do not copy their DNS changes for this email-only setup. If record generation remains pending, use NationBuilder support rather than constructing targets yourself.

Publish DNS without breaking other services

Use the authoritative DNS zone, not necessarily the company that sold your domain. Save the current records before approved changes. Copy each issued record's type, full owner and destination exactly. These are public DNS values; you should never need to publish a DKIM private key.

Check what your DNS editor appends. For the illustrative full owner selector._domainkey.example.org, an editor for the example.org zone may require only selector._domainkey. In a separately delegated _domainkey.example.org zone, the relative name is selector. These are generic DNS owner-format examples, not provider selectors, records to publish or instructions to onboard a child sending domain. A child-zone delegation changes where records must be entered; preserve NS delegations and coordinate with their owner rather than deleting them.

An issued CNAME owner cannot also contain TXT, A, AAAA, MX or another CNAME. If an owner is occupied, investigate dependencies and request a supported alternative where possible; do not overwrite another sender's record. A CNAME destination is a hostname, not a URL, and its trailing-dot treatment depends on the DNS editor. Check the resulting public owner and target instead of trusting the input form alone.

For Cloudflare, authentication aliases should be DNS only, not HTTP-proxied. Where literal CNAME answers are required, turn the applicable per-record Flatten option off when available and ensure whole-zone flattening does not conceal those aliases. Do not disable a global setting without assessing other records and obtaining authorization. Apex flattening is automatic; same-zone targets can be flattened regardless of that setting. If mandatory behavior prevents the required alias answer, stop and coordinate a supported configuration rather than inventing a switch or moving a selector. See Cloudflare proxy status and CNAME flattening controls.

Verify and connect the broadcaster

After publishing the issued records, return to the domain settings and use the refresh control to check that they are active, and confirm the domain status is authenticated. NationBuilder allows up to 48 hours for propagation; first inspect owner/target errors rather than repeatedly regenerating records. A cached result may take time to change, but waiting cannot repair an incorrect owner.

Then open Communication > + New broadcaster and use the custom-domain mailbox that already exists. Review the name and authorized sender access under Settings > Basics and save the broadcaster. Open Settings > Email and save the intended outbound configuration. Do not expand correspondence visibility, enable BCC copies or activate inbound forwarding merely to complete outbound authentication.

NationBuilder states that forwarding from a third-party mailbox affects logging incoming messages, not outgoing mail. It is outside this guide. After saving an email-blast draft, an authentication warning indicates a problem. Absence of the warning is a useful application check, not the final proof of signing. Domain verification and generic fallback; broadcaster settings.

Understand SPF and preserve DMARC

SPF evaluates the SMTP envelope sender, commonly reported as smtp.mailfrom, not automatically the visible From address. A custom routing subdomain and a visible sender domain are different identities. Do not add an apex SPF include merely because the service uses a particular delivery backend. Use only the actual account-issued configuration and investigate the received message's evaluated identity.

If an authorized setup requires an SPF TXT policy, keep one v=spf1 policy at that exact owner, preserving legitimate existing authorizations and qualifiers. The SPF limit is ten evaluated DNS-dependent terms, including nested mechanisms, not simply ten includes. A redirect is ignored when an all mechanism is present. Do not blindly merge or replace a policy, and do not treat a qualifier as a guarantee of delivery or rejection. SPF specification.

DMARC passes when either SPF or DKIM passes and aligns with the visible From. Relaxed alignment uses an Organizational Domain match; strict alignment requires an exact domain match. A child envelope domain may align in relaxed mode but not strict mode. A passing provider-domain signature that does not align is not enough. For the new branded DKIM route, require the intended provider signature to pass and align, even if SPF could independently yield a DMARC pass. Read DKIM alignment and the visible From domain and the current DMARC specification.

Preserve existing direct and applicable inherited DMARC policies and approved reporting destinations. Authentication setup is not permission to downgrade quarantine or reject to none. Only if no applicable policy exists, the owner approves, and a monitoring plan is in place, an initial TXT policy can be v=DMARC1; p=none at _dmarc beneath the actual From domain. For example.org, that full owner is _dmarc.example.org; for news.example.org, it is _dmarc.news.example.org. Enter names relative to the actual authoritative zone and publish only one policy at an owner. This minimal example sends no aggregate reports by itself.

Choose any report recipient deliberately. A destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination within the same Organizational Domain is excepted. DNS authorization does not replace the owner's privacy and data-sharing approval. Do not copy a tutorial's reporting address. See RFC 9990, section 4.

Prove the actual messages authenticate

Provider verification checks DNS configuration. It is not proof that every message stream uses the intended signing domain. After configuration, an authorized administrator should test the actual application route with a controlled, valid recipient. This guide did not perform customer sends or change DNS.

Save the recipient's original message and use authentication results produced inside the actual receiving service's processing boundary. Consult that service's documented handling of externally supplied Authentication-Results, or obtain a receiving administrator's trace. A familiar authserv-id string or header position alone is not proof of authenticity. Ignore injected or otherwise untrusted result fields. Authentication-Results specification.

Record the visible From, envelope sender, intended DKIM signature's signing domain and selector, and the trusted receiver's SPF, DKIM and DMARC results. Acceptance requires the intended provider DKIM signature to pass and align with the intended From under the active alignment policy, plus a trusted receiver DMARC pass. A generic DMARC pass via SPF alone does not prove DKIM works. A rewritten provider From is not proof of brand-domain authentication.

Investigate SPF fail, temperror and permerror separately, even when aligned DKIM makes DMARC pass. Temporary errors suggest a transient lookup problem; permanent errors indicate a configuration/evaluation problem; neither should be silently marked passed. Test materially different sending paths separately. Authentication does not guarantee inbox placement, indexing or search rankings.

Troubleshooting and FAQs

Why does my NationBuilder email show a nationsend address?

NationBuilder documents a generic sender fallback when the broadcaster is unauthenticated, potentially displayed as “via nationsend1-25.com.” Recheck the exact domain associated with the broadcaster and its issued records. Do not count fallback delivery as successful branded authentication.

What is the NationBuilder SPF record?

The reviewed native setup instructions direct you to domain-specific generated CNAME records, not a universal SPF include to paste at your apex. Follow the actual packet and inspect the delivered envelope identity. A provider website's own SPF record is not an instruction to copy it into your domain.

Which DKIM selector should I use?

Use the current records issued for your connected domain. Do not reuse another nation's selector or target, and do not generate a local public/private key pair expecting NationBuilder to use it automatically.

The CNAME records are saved but authentication is still pending

Check the authoritative zone, duplicated domain suffixes, exact record types and complete targets. Check conflicts, proxy status and flattening. If a DNS interface rejects underscores, contact the DNS administrator or provider for a supported solution; do not remove _domainkey or migrate hosting without a separate decision. Allow propagation after correcting actual errors, then refresh NationBuilder's check.

Test emails stopped after changing From

The new address may use a different domain. Confirm that domain is connected and authenticated, and that the broadcaster uses the intended mailbox. Then test that actual route. Authentication of the previous domain does not establish authentication of the new one.

Should I move my website or enable incoming-mail forwarding?

Neither is required for this outbound-only self-managed path. Keep website DNS, MX and mailbox routing unchanged. Forwarding creates a different operational and privacy consequence and needs its own approved plan.

DNS verification passes but DKIM or DMARC fails at the receiver

Compare the delivered From and signing domain with the domain you configured. Use trusted receiving-service evidence and the actual production path. Check whether the message was rewritten or forwarded. Do not weaken DMARC or broadly allowlist messages to hide the mismatch. Give support sanitized timestamps, identifiers, exact DNS owners and authentication results, not credentials or private keys.

Sources and limits

This guide is based on documentary review. No customer account, DNS change, message send, receiving-header test or deployed website rendering was performed. The instructions keep domain authentication separate from website migration and incoming correspondence access; neither a verified DNS badge nor a generic sender fallback is a substitute for the message-level acceptance check.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base