How to Verify a Sending Domain in Sendrealm

A verified sending domain establishes that Sendrealm is authorized to send mail for your brand. It is the foundation for authentication, reputation, and reliable troubleshooting; it is not a guarantee that every message reaches the inbox.

This guide explains how to choose a domain, publish the DNS records shown by Sendrealm, verify the result, and avoid the mistakes that commonly delay a production launch.

Decide whether to use the root domain or a subdomain

You can send from an organizational domain such as example.com or a dedicated subdomain such as notify.example.com.

A subdomain is often useful when the team wants to separate traffic by purpose:

• auth.example.com for password resets and sign-in links
• notify.example.com for product notifications
• marketing.example.com for newsletters and promotions

Separation makes ownership and reputation easier to reason about, but it adds DNS and operational work. A small product with one well-controlled transactional stream may prefer a single domain. Choose a structure the team can maintain consistently.

The visible From address must use the domain you verify. Verifying notify.example.com does not authorize an unrelated example.org address.

Step 1: add the domain in Sendrealm

Open Domains in the correct Sendrealm project and add the exact domain or subdomain you plan to use.

Sendrealm generates the DNS records required for that domain. Treat the values shown in the dashboard as canonical: copy the record type, name, value, priority, and other fields exactly as displayed.

Do not copy records from another Sendrealm project or from a generic tutorial. DKIM selectors and verification values can be specific to the domain and project.

Step 2: publish the records at your DNS provider

Open the authoritative DNS provider for the domain. This may be different from the registrar where the domain was purchased.

For every record shown by Sendrealm:

1. choose the matching record type
2. paste the host or name
3. paste the value or target
4. preserve the priority where applicable
5. save the record

DNS dashboards handle host names differently. Some expect _dmarc; others expect _dmarc.example.com. Some automatically append the zone name and create an invalid duplicate if you paste the full domain. Check the provider's preview of the final hostname.

Avoid multiple SPF records

SPF is published as a TXT record. A domain should not have several independent v=spf1 records. If another service already sends mail for the same domain, combine authorized sources into one valid policy rather than publishing a second SPF policy blindly.

SPF also has a DNS lookup limit. Long chains of include mechanisms can exceed it even when the text looks syntactically correct. Consolidate old providers and remove unused authorization during migrations.

Keep DKIM values unchanged

DKIM uses a selector under _domainkey. Copy the selector and target exactly. Do not reuse a selector from another provider or remove a record until all traffic signed with it has stopped.

Publish DMARC deliberately

DMARC is normally published at _dmarc.example.com. A monitoring policy such as p=none can be a responsible starting point while you confirm legitimate sending sources and alignment. Move to quarantine or reject only after reviewing reports and eliminating unauthorized or misaligned traffic.

Step 3: wait for DNS propagation and verify

DNS changes are not instant. Your provider may publish quickly while recursive resolvers continue to cache an older answer until its TTL expires.

Return to Sendrealm and recheck the domain. Review each record, not only an overall status. If one record remains unverified:

• confirm you edited the authoritative DNS zone
• inspect the fully qualified hostname
• look for quotation marks added to TXT content
• check whether a proxy or flattening feature changed a CNAME
• compare the value character by character
• wait for the previous TTL before making more changes

Repeatedly editing a correct record can extend confusion. Resolve the exact mismatch first.

What SPF, DKIM, and DMARC each prove

These mechanisms work together but answer different questions.

SPF

SPF tells a receiving server which infrastructure may send using the envelope domain. It helps validate the return path, but SPF alone does not guarantee alignment with the domain a recipient sees in the From header.

DKIM

DKIM adds a cryptographic signature tied to a domain. The receiving server uses the public key in DNS to verify that signed message content was not altered after signing.

DMARC

DMARC checks whether the visible From domain aligns with a domain authenticated by SPF or DKIM. It also publishes a requested policy and can provide aggregate reports about authentication results.

Google requires SPF or DKIM for all senders to personal Gmail accounts and SPF, DKIM, and DMARC for senders above its bulk threshold. Yahoo publishes similar bulk-sender requirements. Review the current Gmail sender guidelines and Yahoo Sender Hub requirements because provider policies can change.

Step 4: send a controlled test

After Sendrealm verifies the domain:

1. create a project API key with sending permission
2. send to a controlled mailbox using the API or SMTP
3. inspect the message headers at the recipient
4. confirm SPF, DKIM, and DMARC results
5. review the Sendrealm recipient event timeline

Test both message construction and the user experience. Check the sender name, reply address, links, plain-text alternative, and rendering. Authentication success does not fix a broken confirmation link or misleading sender identity.

Step 5: increase production volume gradually

A newly authenticated domain does not have a mature sending reputation. Start with expected transactional traffic or a recent, engaged audience. Avoid moving years of dormant contacts into one large first campaign.

As volume grows, monitor:

• delivery and delay rates
• hard and soft bounces
• complaints
• unsubscribes
• domain-level reputation signals
• changes by audience source or message type

If deferrals or complaints increase, pause expansion and identify the cause. Authentication proves identity; consent, relevance, list quality, and sending behavior determine how recipients and mailbox providers respond.

Migration without downtime

When moving from another provider:

• add Sendrealm records before removing the old provider
• preserve the old DKIM selector while old mail can still be in flight
• combine SPF authorization safely rather than replacing it prematurely
• verify Sendrealm and run controlled tests
• move one message stream or traffic segment at a time
• monitor both systems during the overlap
• remove old authorization only after the old path is disabled

This sequence keeps rollback possible and avoids a window where neither provider is authenticated.

A reusable launch checklist

• exact domain or subdomain selected
• DNS ownership confirmed
• all Sendrealm records copied exactly
• one valid SPF policy
• DKIM selector resolving
• DMARC published and aligned with rollout plan
• domain verified in the correct project
• sender address matches the verified domain
• API or SMTP test delivered
• headers show authentication results
• suppression and unsubscribe behavior tested
• volume ramp and monitoring owner assigned

Verification is the beginning

Domain verification creates a trustworthy technical identity. Maintaining that identity requires clean lists, recognizable senders, consistent traffic, low complaints, secure credentials, and ongoing monitoring.

Open Sendrealm to add a sending domain, or use the public SPF and DMARC checker for a quick DNS presence check.