Pair Networks SPF, DKIM and DMARC setup, step by step

For Pair-managed mailboxes, configure SPF and activate domain-level DKIM in the Account Control Center (ACC). In the new interface, open Domains → Edit beside the domain → Email, then edit the SPF or DKIM setting and select its activation button. Use the SPF policy and DKIM record issued for your own account; there is no single documented SPF value to copy for every Pair server type. DKIM signs SMTP-authenticated messages only. External DNS requires you to publish the generated records there, then verify the intended aligned DKIM signature and DMARC on received mail. Pair SPF instructions · Pair DKIM instructions

This is a documentary setup guide. No customer account, DNS publication or live message delivery was tested.

In this guide

• Check mailbox eligibility and the actual sending route
• Plan the DNS change
• Configure the correct Pair SPF policy
• Activate DKIM and publish its key
• Preserve or introduce DMARC safely
• Validate the public records and received message
• Troubleshoot Pair SPF and DKIM
• Frequently asked questions

Check mailbox eligibility and the actual sending route

This guide covers Pair-operated mailbox service managed in the ACC, including eligible Pair Platinum Mail add-ons and the mailbox service included with managed VPS or Dedicated hosting. It does not cover configuring a self-managed mail-transfer agent simply because its server is hosted at Pair.

Pair’s current mailbox FAQ says Platinum Mail can be added to current-generation Shared plans, while VPS/Dedicated plans include mailbox service. WordPress offerings and previous-generation accounts have their own entitlements. Check your actual account rather than assuming all hosting includes email. In the new ACC, open your username menu, choose Account Settings, and inspect Account Limits → Mailbox Limit. The legacy interface uses Your Hosting Package Details. A missing mailbox limit means the account does not include mailboxes according to Pair’s instructions. Pair email hosting and mailbox FAQ

You need authorized ACC access for the domain and access to its authoritative DNS host. The domain must be associated with the account’s mailbox service. If the domain or DKIM controls are missing, resolve account ownership and mailbox entitlement before adding speculative DNS records. Pair documents DKIM as available only on packages with mailboxes. DKIM eligibility

Identify what actually submits the message:

• Mail client using the Pair mailbox’s authenticated SMTP service: covered by this procedure.
• Website script using local Sendmail or another unauthenticated route: not covered by Pair’s SMTP-authenticated DKIM promise. Test or reconfigure that application separately with its owner.
• External SMTP, marketing platform or CRM: authenticate the actual sending provider and preserve its records. A Pair-hosted From domain does not establish that Pair sent the message.
• Pair Domains acting only as registrar or DNS host: use the mail provider’s generated records. Pair Domains DNS management is distinct from Pair Networks mailbox activation.
• Webmail, forwarding, autoresponders and other routes: validate each route you rely on. Do not use a mail-client result as proof that every mailbox workflow has identical authentication.

Pair’s client instructions show where to obtain the actual outgoing SMTP server: in the new ACC, select Email, open the cog beside Mailboxes currently configured, and edit the mailbox. Read Outgoing Mail Server (SMTP) from that mailbox’s settings. Use authenticated, encrypted submission; do not trust an email client’s guessed server name. Account generations can have different settings. Pair email client configuration

Plan the DNS change

Save the current zone records and note the responsible DNS administrator. Inventory all legitimate senders that use the same envelope domain, all active DKIM selectors, and the effective DMARC policy and report destinations. Establish which name servers are authoritative, including any separately delegated subdomain.

Changing the registrar’s DNS panel does nothing if another company’s name servers serve the zone. Conversely, registering at Pair Domains does not mean the ACC is automatically updating the authoritative zone. You do not need to migrate name servers, change MX or disable DNSSEC to publish SPF and DKIM TXT records.

Record names must expand to the intended owner

Use these as naming examples, not production values:

• SPF for person@example.com with envelope domain example.com: TXT at example.com. Pair’s custom-DNS instructions use an empty Hostname field for the whole domain.
• DKIM: TXT at the complete owner generated by Pair, typically shaped as SELECTOR._domainkey.example.com. Obtain the actual selector and key from your account.
• DMARC for visible From domain example.com: TXT at _dmarc.example.com.

If your DNS editor appends example.com, the DKIM host field is usually SELECTOR._domainkey, not the whole name repeated. Other editors expect a full name. Inspect the final expanded owner. A separate mail.example.com zone has its own apex: use its blank or @ convention for an SPF record at mail.example.com. In the parent example.com zone, that same owner would normally be mail.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

These documented Pair DKIM records are TXT records, not literal CNAME delegations. There is no CNAME-flattening or website-proxy change to make. A conflicting record at the same owner requires a targeted review of its dependencies, not a broad shared-zone setting change.

Configure the correct Pair SPF policy

Retrieve the account-specific policy

Pair’s preconfigured SPF record is based on your account type and email server configuration, and Pair warns that it can change when those change. Do not borrow another customer’s IP addresses, invent a universal include:pair.com, or infer an SPF policy from the incoming MX servers. Pair’s preconfigured-policy explanation

SPF checks the SMTP envelope domain, normally reported as smtp.mailfrom by the receiving system. It does not directly authorize the visible From address or Reply-To. Before changing a root-domain record, establish which envelope domain the route actually uses. SPF identity, RFC 7208

For the new ACC:

1. Sign in at my.pair.com.
2. Select Domains in the top navigation.
3. Find the intended domain and click Edit.
4. In Email, find Sender Policy Framework (SPF) and click Edit.
5. Inspect the current preconfigured SPF value and compare it with the public policy and your sender inventory.
6. If the default policy is appropriate and will not duplicate or remove an existing sender policy, select Activate SPF.
7. Confirm the resulting record at the authoritative DNS host and through a public resolver.

For the legacy ACC, use Domains → Manage Your Domain Names → domain name → Sender Policy Framework (SPF) → Change SPF Settings. Pair explicitly says this page displays the preconfigured record; choose Activate SPF only after reviewing it. Current and legacy SPF workflows

If the current screen does not expose the policy you need, obtain it from Pair for your account and server type before composing an external or shared-sender record. An activation control in ACC is not evidence that an unrelated DNS provider has changed its zone.

Preserve other senders and existing failure behavior

There must be one SPF record per owner name, not one record per provider. Preserve unrelated TXT records. If a policy already exists, edit the single policy with all legitimate senders accounted for rather than activating a competing default alongside it. Do not paste two complete v=spf1 strings together. SPF record requirements

Pair provides a custom-SPF route for accounts whose needs go beyond the preconfigured policy. In the new ACC, the documented DNS path is Domains → Edit → DNS → Name Servers: Edit → Manage DNS Records. For a new record, choose Add New DNS Entry → TXT → Proceed, set the Hostname and Text Record, then choose Create TXT Record. If an SPF record already exists, edit that record through your DNS controls instead of following the add-new sequence.

The legacy path is Domains → Manage Your Domain Names → domain → Manage Custom DNS Records → Add DNS Records → TXT. External DNS uses that provider’s equivalent TXT editor. The relevant public owner and final policy must be the same regardless of which interface publishes it. Custom SPF instructions

Review the full policy before saving:

• Retain the currently required Pair authorization and all other legitimate senders at that owner.
• Preserve the intended terminal qualifier unless the domain owner has deliberately approved changing it. -all produces SPF fail for unmatched sources; ~all produces softfail. These are authentication results, not guarantees that every recipient will reject or deliver. Local receiver policy still matters. SPF result handling
• Keep DNS-lookup-causing terms within the SPF limit of 10, including nested includes and redirects. Check the actual expanded evaluation, not just the length of the visible record. Also investigate DNS errors and excessive void lookups. SPF processing limits
• Do not convert a provider-managed policy to a permanent IP snapshot unless Pair supplies and supports that configuration.

With external DNS or a manually maintained custom policy, arrange to review it when the account or mail server changes. Pair’s warning about changing defaults is a reason to retain ownership and maintenance notes, not to invent a fixed universal record.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Activate DKIM and publish its key

New ACC workflow

1. Open Domains and click Edit beside the intended mailbox domain.
2. In Email, locate DomainKeys Identified Mail (DKIM) and click Edit.
3. Select Activate DKIM.
4. Inspect the generated DKIM hostname and TXT record value.
5. Follow the correct DNS branch below, then allow the published record to become visible before validating new mail.

For the legacy interface, use Domains → Manage Your Domain Names → domain → DomainKeys Identified Mail (DKIM) → Change DKIM Settings → Activate DKIM. Pair DKIM procedure

Activation affects all mailboxes on the selected domain, but Pair explicitly limits signing to messages sent with SMTP authentication. It does not switch on a universal signer for local scripts, unrelated mail servers or every possible message that happens to show that From domain.

Follow the documented activation order

Pair’s documented order is to activate DKIM in the ACC, then publish the resulting record where necessary. Do not expect an undocumented pre-generation step or assume that an external DNS record was already installed.

• Pair Networks name servers are authoritative: Pair’s companion instructions say the DKIM records are added automatically. Verify that the public owner and value actually resolve.
• Pair Domains Custom DNS is authoritative: copy the ACC’s DKIM Hostname and DKIM TXT Record Value into a TXT record in the Domain Name Management System. Pair Domains is a separate DNS workflow, even though both services use the Pair name.
• Another DNS provider is authoritative: provide the generated TXT record to that DNS administrator or publish it there yourself if authorized. The ACC toggle cannot be treated as confirmation of an external edit.

The Pair Domains DKIM procedure documents the first two branches. If Pair Domains Custom DNS is already active, its path is domain → Edit DNS → Add New Record → TXT. Do not choose Use our DNS merely to follow the tutorial when another provider currently hosts your zone; that changes name servers and can affect the whole domain.

Copy the full generated public key and preserve its pairing with the correct selector. Do not substitute default or another familiar selector unless the current account actually gives you that value. Do not generate an unrelated key pair in a third-party tool: its public key would not match Pair’s signing key.

Keep existing selectors for other services. If a new key conflicts with an occupied owner, identify the existing dependency before changing it. DNS editors may split a long TXT value into several quoted character strings inside one resource record; that is different from publishing multiple conflicting key records at the same owner. Never publish the private signing key or mailbox credentials.

Pair says signing starts after the new DKIM record is published and asks customers to allow time for it to take effect. It does not provide a universal completion timer in the DKIM procedure. Check authoritative publication, resolver caching and a fresh received message instead of declaring success after a fixed wait.

Preserve or introduce DMARC safely

DMARC passes when at least one passing SPF or DKIM identity aligns with the visible From domain. SPF alignment uses the authenticated envelope domain; DKIM alignment uses the signing domain in d=. Strict aspf=s or adkim=s requires an exact match. Relaxed alignment allows the appropriate organizational-domain match. Neither a working SMTP login nor an SPF record at the visible domain proves alignment. DMARC identifier alignment

Query the policy at _dmarc under the From domain and establish any applicable parent or organizational-domain policy. A missing direct record for a subdomain does not establish that it has no DMARC policy. Preserve existing enforcement, alignment modes, reporting destinations and subdomain settings. Repair a malformed or duplicate policy with the owner rather than adding a competing record or weakening an inherited policy. Policy discovery

Only when there is no direct or inherited policy, and the domain owner chooses a first non-enforcing policy, the minimal example for example.com is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

Use _dmarc in an example.com zone whose editor appends the suffix. For visible From domain mail.example.com, the full owner is _dmarc.mail.example.com: use _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. Confirm the final name before saving.

This starter does not request reports. Add rua only for an approved, operational reporting destination. If the reporting destination is outside the policy domain’s organizational domain, arrange the required destination-side DNS authorization for that reporting relationship and approve the privacy implications. Aggregate reports can reveal sending infrastructure and authentication metadata; establish who can access them and how long they are retained. Do not enable reports to an arbitrary example mailbox, or add failure-reporting destinations casually. DMARC aggregate reporting

Before deploying that first non-enforcing policy, agree an appropriate monitoring and review plan with the domain owner: identify who will review authentication evidence, which reporting or receiver-side diagnostic sources they will use, and when unresolved senders will be assessed. The minimal record need not contain rua; choose monitoring deliberately rather than assuming the record itself collects reports. Preserve the absence-of-direct-or-inherited-policy condition above.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, 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 that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Do not lower an existing p=quarantine or p=reject policy for the setup. Consider enforcement changes only after all legitimate senders and representative reporting evidence have been reviewed.

Validate the public records and received message

First establish the DNS evidence

Use your actual domain and the generated DKIM owner. These command examples contain placeholders and do not establish that any real deployment works:

dig NS example.com +short
dig @AUTHORITATIVE_NS example.com TXT +noall +answer
dig @AUTHORITATIVE_NS SELECTOR._domainkey.example.com TXT +noall +answer
dig @1.1.1.1 example.com TXT +noall +answer
dig @1.1.1.1 SELECTOR._domainkey.example.com TXT +noall +answer
dig @1.1.1.1 _dmarc.example.com TXT +noall +answer

For a delegated subdomain, discover its authoritative servers rather than assuming the apex’s servers answer. Compare the authoritative answer and a public recursive resolver after relevant TTLs expire. Expect one SPF policy at the actual envelope domain, the exact generated DKIM public key at its owner, and the intended DMARC policy with inheritance considered separately.

If the DNS editor has saved a record but the authoritative server does not answer with it, investigate the zone or owner rather than waiting indefinitely. If the authoritative answer is correct but a resolver differs, inspect caching and TTLs. An old negative answer can also be cached.

Then test an SMTP-authenticated mailbox message

Send a new message from the intended Pair mailbox through its configured authenticated outgoing SMTP service to an independent mailbox you control. Keep the received original. Record the sending route, timestamp and visible From address, then inspect raw headers or the receiving system’s message trace.

Use only results from receiving infrastructure you control or trust. An attacker can prepend a convincing Authentication-Results field, including a familiar authserv-id. If the receiver cannot distinguish or remove untrusted fields, use an independent trusted recipient or receiver-side trace rather than relying on that string. RFC 8601 security requirements

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For the route under test, verify:

1. SPF authorization: the receiver reports spf=pass for the actual smtp.mailfrom identity on a direct properly authorized send. Record the identity and sending IP, not just the word “pass.”
2. SPF alignment: compare that envelope domain with the visible From domain under the effective aspf setting. If SPF passes but is unaligned, do not call it an SPF failure or assume a root SPF edit will change the envelope identity.
3. Intended DKIM signing: the Pair-generated signature is present, its d= domain and s= selector identify the expected key, and the trusted receiver reports that signature as dkim=pass. The d= domain must align under the effective adkim setting.
4. DMARC: the trusted receiver reports dmarc=pass for the intended visible From domain.

A DMARC pass supplied only by SPF does not prove that your newly enabled DKIM works. A passing signature belonging to an unrelated provider domain does not prove branded DKIM either. Require the intended aligned Pair DKIM pass plus DMARC pass before closing this setup task. Pair’s public procedure does not establish the exact emitted envelope identity or selector for your account; the received sample must settle those facts.

When several DKIM signatures appear, keep each signature’s d= and s= together. EmailAuth’s DKIM selector guide shows how to derive the correct lookup without mixing identities from different signatures.

Do not ignore independent SPF problems because DKIM supplies a DMARC pass. Investigate fail as a potential unauthorized sender or route problem, temperror as a temporary evaluation problem, and permerror as a malformed, duplicated or over-budget policy. Retest after the specific repair. Repeat separately for every application or alternate route you depend on.

Troubleshoot Pair SPF and DKIM

The DKIM option is missing

Check that the correct hosting account and domain are selected and that the account has mailbox service. The DKIM procedure does not apply to a DNS-only account or self-managed MTA. If the package should qualify, ask Pair to confirm entitlement and the appropriate current ACC controls before changing DNS.

DKIM is enabled, but no signature appears

First verify SMTP authentication, the outgoing server and the mailbox used. A website using a local unauthenticated delivery path is outside Pair’s signing promise. Confirm that the message was sent after activation and DNS publication, and that a client did not silently use another SMTP account. Do not generate new DNS keys to repair a submission-route problem.

The signature exists, but its key is missing or different

Query the owner built from the actual d= and s= values. Compare it with the current ACC record, including the full public key. Check for a duplicated domain suffix, wrong zone, missing external publication, cached negative answer or retired selector. Preserve existing keys while establishing which route still uses them.

SPF returns permerror

Look for more than one v=spf1 record, invalid syntax, duplicated modifiers, or nested lookup exhaustion. Review the full policy, including other vendors’ dependencies. Deleting an unrelated sender simply to reduce the lookup count can break legitimate mail; plan a supported correction instead.

Pair mail passes, but another sender now fails

A default policy may have displaced that sender or a second SPF record may have been created. Restore the intended sender coverage in one valid policy, without changing unrelated TXT, MX or DKIM records. Confirm both sending routes with new samples rather than assuming the repair is symmetric.

All authentication checks pass, but the message is rejected or spammed

Authentication is one input to recipient filtering. Inspect the SMTP rejection response, content, reputation and recipient expectations. A pass does not guarantee acceptance or inbox placement, and switching SPF from hardfail to softfail is not a general deliverability repair.

For support, retain the account’s generated record details, authoritative DNS answers, route and timestamp, and trusted authentication results. Redact message content and personal addresses before sharing where possible. Never send mailbox passwords or private keys.