Porkbun SPF, DKIM and DMARC setup, step by step

No customer account, DNS change or sending test was performed.

For Porkbun hosted email, use the mailbox service's DKIM/DMARC configuration and publish its account-generated records at the authoritative DNS host. If Porkbun only hosts your DNS, obtain authentication records from the service that actually sends your mail. Domain registration alone does not identify that sender.

This guide preserves both tasks: authenticating an existing Porkbun hosted mailbox and publishing sender-issued records in Porkbun DNS. It is not a mailbox purchase, mail-server installation, nameserver migration or forwarding setup guide.

Choose the right path before touching DNS

Write down the visible From domain, mailbox or application sending the message, actual outbound service, DNS administrator and existing authentication policy. Separate hosted-mailbox sending, inbound forwarding, third-party mailboxes and website forms. A website registered at Porkbun may send through an entirely different system.

Confirm authority using public delegation and the DNS administrator's zone inventory. An editable zone in a registrar account is not proof that receivers query it. Check child-zone and _domainkey delegations separately. Keep existing MX, parent nameservers, DNSSEC, forwarding destinations and credentials unchanged. Authentication work does not implicitly authorize a migration.

Obtain permission for the precise change and save existing record owners, types, values and TTLs. Inventory other senders before modifying shared SPF or DMARC. For an external sender, obtain its complete account-specific record packet and signing-activation instructions for the correct product and region. Do not infer tenant targets from another customer's screenshot.

Enable authentication for an existing Porkbun mailbox

Porkbun's hosted-email instructions, describe this flow:

1. Open ACCOUNT → Domain Management and choose the domain's envelope icon in the EMAIL column.
2. On Email Hosting and Forwarding, find Additional Notices & Configuration → DMARC Notice.
3. Configure DMARC also configures DKIM. The button requires an email-hosting service for that domain.
4. After reviewing the proposed effects, confirm the configuration. A second notice reports that records are queued. Refresh after the documented five-to-ten-minute interval to inspect the resulting status.

Do not approve an automatic policy replacement blindly. First compare existing direct and inherited DMARC, report recipients and active keys. If the interface does not establish how they will be preserved, ask Porkbun support to reconcile the change before proceeding. Queued or configured is not delivered-message proof. Avoid Delete or Reset as routine troubleshooting.

A DMARC Warning can indicate third-party authoritative nameservers. Use the external-DNS path below rather than changing nameservers to remove the warning. If the button is absent, verify the mailbox entitlement and domain selection; DNS registration alone does not unlock hosted-mail signing.

Copy hosted-mail records when DNS is elsewhere

Porkbun's external-DNS instructions, identify the hosted-email SPF include as include:_spf.porkbun.com. Their standalone policy is:

v=spf1 include:_spf.porkbun.com ~all

Porkbun documents this TXT at the hosted domain apex, with Host blank or @ according to the external DNS editor. Keep that native publishing instruction separate from checking the actual MAIL FROM identity: do not relocate this record to an observed bounce domain by guessing. This is a documented hosted-mail example, not a replacement for a multi-sender policy. Do not add this include merely because Porkbun registered your domain.

When hosted DKIM/DMARC has been configured, open the domain's Details → DNS Records edit control. In the TXT section, obtain the actual Host and Answer for default._domainkey and _dmarc. Copy the complete public DKIM value, including its tags and full key, to the authoritative provider. Use the account's current record packet rather than treating a sample key as universal. If no generated packet is available, resolve that with Porkbun instead of fabricating one.

The same vendor article also covers inbound-mail migration. Its MX replacement recipe is not an authentication-only instruction. Retain working inbound routes unless a separate migration is approved. Reconcile the generated DMARC policy with existing protection before publication.

Add or edit records in Porkbun DNS

Use this section only where Porkbun is authoritative. The current DNS editor guide, documents ACCOUNT → Domain Management → Details → DNS Records and its edit icon.

For a new owner, open Manage DNS Records → Add Record, enter the intended type and fields, select Add, then Back to inspect the saved row. For an existing policy, use that row's pencil icon and Save. Do not create a second SPF or DMARC policy while trying to update the first. If an edit fails, diagnose the conflict before deleting working records.

The record-field reference, specifies:

• Type: choose TXT or the sender-issued CNAME type exactly.
• Host: leave blank for the selected root domain; enter the relative subdomain otherwise.
• Answer/Value: enter the complete TXT value or issued CNAME hostname, not a website URL.
• TTL: seconds; retain the existing/default value unless the approved change plan requires another.
• Notes: optional internal annotation, not published authentication data.

After saving, verify the full public owner. A correct-looking row is insufficient if it is under the wrong zone.

Map full names and preserve delegations

These are illustrative DNS-name mappings, not issued selectors or proof that your account supports a separately hosted child zone:

Replace illustrative domains and selectors with the approved full owners. Do not enter a full name into a relative field and accidentally create a doubled suffix. Where news.example.com or _domainkey.example.com is delegated, publish at that child authority. A parent-zone record below the delegation will not replace the child's answer. Coordinate with its administrator rather than deleting the delegation or inventing a Porkbun child-zone control.

Preserve SPF and the real envelope identity

SPF evaluates SMTP MAIL FROM, or HELO in applicable cases, not automatically the visible From header. Identify the actual evaluated domain from a trusted message result. Do not assume Porkbun offers a configurable custom Return-Path because a DNS field exists.

Publish one v=spf1 TXT policy at the evaluated owner. Preserve legitimate senders, qualifiers and unrelated TXT verification records. Add any approved authorization within the reviewed policy before its terminating all; do not concatenate two complete policies. A redirect is ignored if the record contains all.

The limit is ten evaluated DNS-dependent terms, including nested dependencies, not ten visible includes. include, a, mx, ptr, exists and redirect consume that budget; ip4, ip6 and all do not. Test the resulting evaluation, including existing dependencies. ~all and -all do not guarantee inbox delivery or rejection. See RFC 7208.

For a shared policy, use EmailAuth's multiple-SPF-record repair guide to inventory and reconcile senders before saving.

Keep DKIM records literal and signing separate

Porkbun hosted mail uses its generated TXT packet. Another sender may issue TXT keys or CNAME aliases: preserve the issued type, every selector and complete value. Publish public keys only, never private keys. Domain ownership verification, DNS publication and outbound signing activation are different milestones. Complete the actual sender's activation workflow after publication.

For CNAME-based packets, use CNAME, not ALIAS - CNAME flattening. Porkbun's ALIAS documentation describes a website-address mechanism; it is not a substitute for a required literal DKIM alias. Porkbun's record reference distinguishes ALIAS A/AAAA behavior from CNAME. Keep the issued alias observable in DNS and its destination resolvable.

At a CNAME owner, do not add conflicting TXT, A, AAAA, MX or another CNAME. Porkbun's CNAME/ALIAS conflict article addresses website parking and replacement. Do not generalize its deletion advice to live authentication selectors, shared web records or NS delegations. Determine ownership and dependencies first.

If the authoritative host is elsewhere, keep authentication aliases DNS-only, not HTTP-proxied. Check per-record, whole-zone, apex and same-zone flattening behavior. Turn an applicable per-record flatten option off where available and ensure zone settings do not suppress the required literal CNAME. Do not globally disable unrelated behavior. If mandatory behavior cannot preserve the alias, stop and coordinate a supported design. No equivalent Porkbun proxy or global flattening switch is asserted here.

Set DMARC without weakening existing protection

Inspect the policy applying to the visible From domain, including inherited policy, before accepting a generated record. Preserve working enforcement, alignment settings and authorized reporting destinations. Do not duplicate _dmarc or automatically replace a policy with p=none.

Only when no direct or applicable inherited policy exists, the owner approves a first monitoring policy and someone will review reports, this illustrative TXT layout can be considered:

Full owner: _dmarc.example.com
Porkbun zone: example.com
Host: _dmarc
Type: TXT
Answer: v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX

Replace YOUR_APPROVED_REPORT_MAILBOX with the approved mailbox address only, not a full mailto: URI, because the prefix is already present. Replace the placeholder before publication. Monitoring is not an enforcement policy. The owner must approve report sharing. A report destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; one within the same Organizational Domain is excepted. A different hostname alone does not trigger this rule. See RFC 9990 section 4. The reporting service supplies its authorization arrangement; do not copy another organization's report address.

Under RFC 9989 section 7.4, a domain publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures. General-purpose mail and mailing-list participation need particular interoperability review. Do not weaken an existing policy as a troubleshooting shortcut or tighten it merely because one test passed.

Verify DNS, then test the intended route

These commands are a test plan, not captured results. Replace example domains, selector and authoritative-server placeholder with approved values. The DKIM lookup must follow the message's actual s= selector and d= domain, not an assumed universal selector.

dig NS example.com +short
dig @YOUR_AUTHORITATIVE_NAMESERVER TXT example.com +noall +answer
dig @YOUR_AUTHORITATIVE_NAMESERVER TXT default._domainkey.example.com +noall +answer
dig @YOUR_AUTHORITATIVE_NAMESERVER TXT _dmarc.example.com +noall +answer
dig CNAME selector._domainkey.example.com +noall +answer

Check each authoritative server, then recursive answers after relevant positive or negative cache lifetimes. Confirm one SPF policy, the approved DMARC policy and the exact full DKIM public value or required CNAME chain. Split quoted strings within one TXT resource record are not automatically multiple records. Do not mistake cached data, NXDOMAIN, no answer and SERVFAIL for the same condition.

Send a harmless message from the actual hosted mailbox through its normal approved outbound path to a controlled external recipient. Test each separately configured application route independently. Save the original message, time and message ID. Test forwarding separately after the direct-send baseline; a forwarded sample cannot establish the original route's SPF behavior.

Use only authentication results produced inside the receiving service's known processing boundary. Confirm with its documentation or administrator how externally supplied Authentication-Results are removed or isolated; use receiver logs if header provenance remains uncertain. Neither header position nor a familiar authserv-id string proves trust. Ignore attacker-supplied fields. RFC 8601 section 7.1 explains this forgery risk.

For the newly configured branded DKIM route, require all of these:

• The intended signature passes, with its actual d= and s= recorded.
• That passing identity aligns with the intended visible From under the active adkim policy.
• The trusted receiver reports dmarc=pass for that From domain.
• SPF is inspected independently using the evaluated smtp.mailfrom identity and connecting IP.

Strict alignment requires identical domains; relaxed alignment compares Organizational Domains. A child envelope domain does not guarantee strict SPF alignment. A DMARC pass achieved only through SPF does not prove DKIM works. A rewritten provider From is not successful authentication of the intended brand. A passing unrelated signature is not the intended aligned signature. The DKIM specification defines the selector/domain lookup relationship.

Troubleshoot the failed layer

Keep SPF errors visible even where aligned DKIM produces DMARC pass. Authentication success is not an inbox-placement guarantee.

Rollback and maintenance

Retain before-and-after snapshots and a named change owner. If a newly edited record is wrong, restore the approved last-known-good value at that exact owner after checking concurrent changes. Do not reset the whole zone or remove other services' selectors. DKIM rollback must match the sender's active key; restoring an obsolete public key alone can break new mail. Coordinate rotations, overlap and retirement with the sender, then repeat DNS and message checks.

For support, provide the product, affected domain, record owner/type, timestamp, redacted message ID and observed failure layer. Never include mailbox passwords or private signing keys. Recheck after sender migrations, policy changes and key rotation.