How to Add SPF, DKIM, DMARC, and Return-Path Records in Porkbun

If you need to add SPF DKIM DMARC records in Porkbun, the hard part is usually not the DNS syntax—it is translating the email provider’s fully qualified record names into Porkbun’s relative Host field without creating the wrong hostname. This guide shows the exact Porkbun workflow, the record shapes to expect, and how SPF, DKIM, DMARC, and a custom return-path work together.

Before You Change DNS: Confirm Where Your DNS Is Hosted

Buying a domain from Porkbun does not automatically mean Porkbun is the authoritative DNS provider for that domain. You may have registered example.com at Porkbun but later changed its nameservers to Cloudflare, a website host, another registrar, or an enterprise DNS service.

That distinction matters because email authentication records must be published at the authoritative DNS provider. Adding a TXT or CNAME record in Porkbun will not help if public DNS for the domain is served elsewhere.

Start by checking the nameservers configured for the domain. If the domain is using Porkbun’s nameservers, manage the records in Porkbun. If you see third-party nameservers instead, add the records in that third party’s DNS dashboard.

This is one of the most common reasons an email platform says a record is missing even though you can see it in a registrar dashboard. The record may exist in a zone that is not live on the public internet.

Know which domain you are authenticating

Before copying any DNS record, identify the exact domain or subdomain your sending platform is asking you to verify. These are not always the same:

• Root domain: example.com
• Sending subdomain: updates.example.com, notify.example.com, or mail.example.com
• Return-path or bounce subdomain: send.example.com, bounce.example.com, or a provider-specific hostname
• DKIM selector hostname: selector1._domainkey.example.com
• DMARC hostname: _dmarc.example.com

A provider might let you send visible messages from news@example.com while using send.example.com for the envelope sender and bounce handling. That arrangement is normal. It can also improve reputation isolation: a marketing stream, product-notification stream, and receipt stream do not all need to share the exact same technical sending identity.

For a transactional email platform, use the domain records displayed in its domain-verification screen as the source of truth. Providers generate unique DKIM selectors, CNAME targets, and return-path values. Do not substitute values from a generic blog post, another account, or another domain. If you are configuring a Volanea sending domain, use the domain-specific values in the email API setup documentation.

The Porkbun Navigation Path for DNS Management

As of writing, Porkbun’s documented route to DNS management begins in Domain Management. After signing in, you should normally land there. If you are already in another area of the account, select ACCOUNT in the upper-right corner and choose Domain Management.

From the Domain Management list, find the domain you want to edit. Porkbun provides two documented ways to open DNS management:

1. Select the DNS button shown under the domain name. This is the quickest route.
2. Or select Details to the right of the domain, locate DNS Records in the details panel, and use its edit icon.

Either route opens Manage DNS Records. This page lists the records currently published in Porkbun’s DNS zone for the domain. Select Add Record to open the record form, choose a record type, fill in the Host and Answer/Value fields, leave TTL at its default unless your provider specifies otherwise, then select Add to save it. Porkbun describes the Host field as the hostname or subdomain and the Answer/Value field as the destination or record content. (kb.porkbun.com)

What the important Porkbun fields mean

The labels are straightforward once you map them to the terminology an email provider uses:

Porkbun’s DNS interface treats a blank Host as the root domain. For example, a TXT record with a blank Host is published at example.com; a Host of send is published at send.example.com; and a Host of _dmarc is published at _dmarc.example.com. (kb.porkbun.com)

The DNS Record Shapes You Need

Your provider’s exact values will differ, but the following table shows the normal shape of SPF, DKIM, DMARC, and custom return-path records in Porkbun.

Use example.com only as a placeholder. Replace every example selector, subdomain, email address, public key, and target with the value supplied by your email provider.

The key idea is simple: the Host says where the record lives beneath your domain, while Answer / Value says what the record contains or points to. The Host is usually relative in Porkbun; the provider’s record display may show the full hostname.

For example, if an email provider displays this DKIM name:

selector1._domainkey.example.com

and your Porkbun zone is for example.com, enter this in Porkbun’s Host field:

selector1._domainkey

Do not enter selector1._domainkey.example.com unless the provider or Porkbun explicitly instructs you to do so. Porkbun’s own documentation says the Host is the subdomain portion, and provider-specific Porkbun guidance similarly instructs users to omit their base domain from a Host such as send.example.com or resend._domainkey.example.com. (kb.porkbun.com)

Add SPF Records in Porkbun

SPF, short for Sender Policy Framework, is a TXT policy that lists the systems allowed to send mail for a domain or subdomain. Receiving mailbox providers evaluate it against the domain used in the SMTP envelope sender, commonly called the MAIL FROM or return-path domain.

That last detail is important. SPF does not directly authenticate the visible address in the From: header. DMARC later determines whether the SPF-authenticated domain is aligned with that visible From domain.

Find your existing SPF record first

Before adding anything, look through Porkbun’s DNS records for existing TXT values beginning with:

v=spf1

A domain must have one SPF TXT record per hostname. Publishing two separate SPF records at example.com is not a safe way to authorize two services. It can produce an SPF PermError, causing receivers to treat the SPF result as invalid.

For example, this is wrong if both TXT records are at the root domain:

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

v=spf1 include:provider.example ~all

Instead, merge the authorized mechanisms into one record, after confirming the correct include value with each provider:

v=spf1 include:_spf.google.com include:provider.example ~all

Do not merge records by guesswork. Existing mail may come from Google Workspace, Microsoft 365, a support platform, a CRM, an ecommerce system, a marketing platform, or a dedicated email API. Removing one authorization mechanism can make a legitimate system fail SPF.

Add a root-domain SPF record

If your provider tells you to add SPF for example.com, use these steps:

1. In Manage DNS Records, select Add Record.
2. Set Type to TXT.
3. Leave Host blank for the root domain.
4. Paste the provider’s complete SPF policy into Answer / Value.
5. Leave the default TTL unless instructed otherwise.
6. Select Add.

A generic example is:

Type: TXT
Host: [blank]
Answer / Value: v=spf1 include:provider.example ~all

The actual include domain is provider-specific. It may not literally be provider.example, and some platforms use a custom return-path arrangement rather than asking you to publish a root SPF record.

Add SPF for a sending subdomain

A dedicated sending subdomain is often cleaner. If your application sends from updates.example.com, the provider may request an SPF TXT record at that subdomain instead of the root.

In Porkbun, use:

Type: TXT
Host: updates
Answer / Value: v=spf1 include:provider.example ~all

If the provider calls the sending subdomain send, enter only send in Host. Porkbun guidance for a provider record shown at send.example.com specifically maps the Host to send, not the full domain name. (resend.com)

SPF’s lookup limit matters

SPF evaluation has a limit of ten DNS-querying mechanisms and modifiers. A long chain of nested include: statements can exceed that limit even if the record looks syntactically valid. This often happens when a domain accumulates several sending services over time.

The practical implication is to keep your sending architecture intentional. Retire old vendors, remove stale includes only after verifying that they are no longer used, and avoid adding every SaaS platform to root-domain SPF by default. A dedicated subdomain can reduce complexity and make ownership clearer.

The ~all mechanism is commonly used during initial setup. It signals a soft fail for sources not authorized by the record. Some organizations later use -all once they have fully inventoried all legitimate sources, but that decision should follow testing—not precede it.

Add DKIM Records in Porkbun

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to mail. The sending service signs each message with a private key, while recipients retrieve the corresponding public key through DNS. That lets receiving systems verify that the message was signed for the domain and has not been altered after signing.

Unlike SPF, DKIM is selector-based. The DNS hostname includes a selector before ._domainkey, so a domain can publish multiple DKIM records simultaneously for different providers or for key rotation.

DKIM can be TXT or CNAME

Your provider will generally ask for one of two patterns:

1. TXT DKIM: You publish a long public key directly in Porkbun.
2. CNAME DKIM: You publish a CNAME that delegates the selector hostname to a provider-controlled hostname.

Both are valid. Do not change a DKIM record from TXT to CNAME—or the reverse—unless the provider specifically gives you that type and value.

A TXT DKIM record might look like this:

Type: TXT
Host: v2026._domainkey
Answer / Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...long-public-key...

A CNAME DKIM record might look like this:

Type: CNAME
Host: s1._domainkey
Answer / Value: s1.example.provider-dkim.net

The selector and destination above are illustrative only. Copy your sending provider’s records exactly.

The Porkbun Host-field mistake that breaks verification

The most common Porkbun-specific configuration error is putting the root domain into the Host field when Porkbun already appends that domain for the zone.

Suppose your sending platform gives this CNAME record:

Host: s1._domainkey.example.com
Value: s1.example.provider-dkim.net

For a Porkbun DNS zone for example.com, the right entry is normally:

Type: CNAME
Host: s1._domainkey
Answer / Value: s1.example.provider-dkim.net

If you paste the entire hostname into Host, you risk creating a hostname equivalent to:

s1._domainkey.example.com.example.com

The same issue affects TXT DKIM records, SPF records on subdomains, return-path CNAMEs, and DMARC records. Enter _dmarc, not _dmarc.example.com; enter pm_bounces, not pm_bounces.example.com; enter selector._domainkey, not selector._domainkey.example.com.

Porkbun documents Host as the subdomain portion of the record and says to leave it blank for the root. Provider instructions written specifically for Porkbun also say to omit the domain from fully qualified record names before pasting them into the Host field. (kb.porkbun.com)

Preserve the DKIM value exactly

For TXT DKIM records, copy the key without adding spaces, line breaks, quotes, or a second p= parameter. DKIM public keys are long, and visual wrapping in a provider dashboard does not necessarily mean you should add manual line breaks.

If Porkbun accepts the entry, leave it as entered. DNS software may represent a long TXT value as multiple quoted strings when queried, but that does not necessarily mean the record is broken. What matters is that the resolved text reconstructs the exact intended value and the provider verifies it.

For CNAME DKIM records, preserve the provider’s target exactly. Do not point the record at your website, mail host, or root domain. A DKIM CNAME is a delegation to where the provider publishes signing-key information.

Avoid CNAME collisions

A hostname that has a CNAME record cannot also have unrelated record types at that same hostname. If Porkbun reports that a CNAME or ALIAS record already exists for the host, inspect the current records carefully. You may have an obsolete provider’s CNAME at the exact DKIM selector or return-path label you are trying to use.

Do not delete a record simply because its name looks unfamiliar. First identify the service that created it, confirm whether it is still sending mail, and verify whether a replacement selector or a new subdomain is safer. Porkbun notes that CNAME/ALIAS conflicts commonly result from older records left over after a hosting-provider change. (kb.porkbun.com)

Add a Custom Return-Path CNAME

A return-path, also called the envelope-from or MAIL FROM domain, is where bounces and certain delivery feedback are routed. It is different from the visible From: address recipients see in their email client.

For example, a recipient may see:

From: Acme Updates <updates@example.com>

while the SMTP envelope sender is technically associated with a subdomain such as:

bounce@send.example.com

A custom return-path lets your email provider use a domain beneath your control instead of a generic shared provider domain. This can allow SPF to align with the visible From domain for DMARC purposes, depending on the domain structure and provider setup.

What to enter in Porkbun

A custom return-path usually uses a CNAME record. The provider gives you a host label and a destination.

A representative shape is:

Type: CNAME
Host: pm_bounces
Answer / Value: pm.mtasv.net

That publishes:

pm_bounces.example.com CNAME pm.mtasv.net

The hostname and destination vary by provider. For example, Postmark documents a default return-path hostname of pm_bounces and a CNAME target of pm.mtasv.net, while also advising users to use the precise Hostname and Value displayed in that domain’s DNS Settings. (postmarkapp.com)

Never assume one provider’s return-path target works for another platform. A custom return-path record is linked to the provider’s sending infrastructure and often to its verification logic.

Why return-path records improve DMARC alignment

DMARC checks whether SPF or DKIM passes and aligns with the visible From domain. Alignment can be strict or relaxed. With relaxed alignment, a subdomain may align with its organizational domain. For example, send.example.com can usually align with example.com under the usual relaxed setting.

If a provider sends mail using its own unrelated envelope-from domain, SPF may technically pass for that provider domain but not align with your From: example.com address. In that situation, a properly configured custom return-path can make SPF alignment possible.

DKIM can independently satisfy DMARC if it passes and aligns, which is why DKIM remains essential even when you have a custom return-path. The resilient configuration is not “SPF or DKIM.” It is both SPF and DKIM working correctly, with DMARC monitoring and enforcing the relationship to your visible From domain.

Add a DMARC Record in Porkbun

DMARC, short for Domain-based Message Authentication, Reporting, and Conformance, tells receiving systems how to handle messages that claim to be from your domain but fail authentication and alignment checks. It also gives you a way to request aggregate reports about mail using your domain.

DMARC is always published as a TXT record at _dmarc under the domain being protected.

For example.com, the basic Porkbun entry is:

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

That produces a record at:

_dmarc.example.com

A DMARC policy can be none, quarantine, or reject. p=none asks receivers to monitor and report. p=quarantine asks them to treat failing messages suspiciously, commonly by placing them in spam. p=reject asks them to reject failing messages outright.

DMARC requires either aligned SPF or aligned DKIM to pass. A message that passes both SPF and DKIM but has neither aligned with the domain in the visible From header can still fail DMARC. Conversely, a message can pass DMARC if either SPF or DKIM passes with alignment. (resend.com)

Start with monitoring, not enforcement

For most domains, start with a reporting policy:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

This lets you identify all real sending sources before taking action against failures. The reports are XML files, often compressed, and can be noisy for teams that have never reviewed them before. Use a dedicated mailbox or a DMARC reporting service instead of sending reports to an inbox that nobody monitors.

A cautious rollout looks like this:

1. Publish p=none and collect reports long enough to observe all legitimate senders, including monthly billing tools and rarely used support systems.
2. Fix missing DKIM, unauthorized SPF sources, and alignment problems.
3. Move to p=quarantine; pct=25 or another measured rollout when you understand the report data.
4. Increase the percentage gradually.
5. Move to p=reject only when legitimate mail reliably passes.

The exact timing depends on how many systems send as your domain. A simple application with one transactional provider may move faster than a company with multiple marketing, sales, support, billing, HR, and workspace systems.

Use a valid reporting mailbox

The rua tag specifies where aggregate DMARC reports should go:

rua=mailto:dmarc-reports@example.com

Use an address that can receive messages. If the reporting address is on a different domain, additional authorization requirements can apply, so a mailbox on the same domain is a simpler starting point.

Do not confuse aggregate reports with message forwarding. DMARC reports summarize authentication results from participating receivers; they do not send copies of customer emails to you.

A Safe Porkbun Setup Workflow

The following workflow reduces the chance of interrupting existing mail or publishing records at the wrong hostname.

1. Inventory current records and senders

Before adding anything, export or copy the existing DNS records. Look especially for:

• TXT records beginning with v=spf1
• TXT records at _dmarc
• TXT or CNAME records containing ._domainkey
• CNAME records named bounce, mail, send, pm_bounces, or provider-specific labels
• MX records for business inboxes or inbound routing

Then list every system that sends mail as your domain. Include employee mailboxes, product receipts, password resets, customer-support tools, marketing systems, invoicing platforms, form tools, and monitoring services.

2. Add the provider’s records without changing unrelated records

Email authentication records usually coexist safely with website A, AAAA, ALIAS, CNAME, and TXT records. Do not delete web or mailbox records just because you are adding a sending platform.

The exception is a direct hostname conflict. If a provider needs a CNAME at s1._domainkey, but a record already exists at that exact host, pause and investigate. Reusing an existing selector or return-path hostname can disrupt an older sender.

3. Keep the Host relative in Porkbun

For every fully qualified name shown by your provider, remove .example.com before placing it in Porkbun’s Host field.

Examples:

This conversion is the step to slow down on. A record can save successfully in Porkbun and still be invisible to the email platform if it was published at selector._domainkey.example.com.example.com instead of the intended name.

4. Wait, then verify from two places

After saving records, use both:

• The verification control in your email provider’s domain dashboard.
• An independent DNS lookup or email-authentication inspection tool.

Verification can take from a few minutes to longer, depending on DNS caching and the provider’s checking schedule. Porkbun’s TTL setting affects how long resolvers may retain an earlier answer, but propagation is not a single global timer. Do not make repeated edits every few minutes unless you identify a real mistake; constant changes make troubleshooting harder.

5. Send a real test message and inspect authentication results

A green verification badge proves the provider can find a DNS record. It is not the final test. Send a message from the actual application or campaign path to a mailbox you control and inspect the message headers.

Look for results similar to:

spf=pass
 dkim=pass
 dmarc=pass

Also check which domains appear beside those results. A message might show spf=pass for a provider domain but dmarc=fail for your visible From domain because alignment is missing. That is exactly the sort of issue a custom return-path and correctly aligned DKIM are meant to address.

Troubleshooting Failed Verification in Porkbun

When verification fails, work from DNS name to record type to value. Avoid randomly deleting and recreating everything.

The provider says the record is missing

Check these items in order:

1. Authoritative DNS: Are the domain’s live nameservers actually Porkbun’s?
2. Host conversion: Did you enter only the relative Host label rather than the full example.com hostname?
3. Record type: Did the provider request TXT, CNAME, or MX? A correct value under the wrong type fails.
4. Exact value: Did you copy the destination or TXT value exactly, without truncating a DKIM key?
5. Correct domain: Did you add a record for example.com while verifying updates.example.com, or vice versa?
6. Caching: Has enough time passed for resolvers and the provider’s verification job to see the new record?

SPF fails after adding another service

Look for multiple root SPF TXT records. Consolidate all legitimate mechanisms into one SPF policy at that hostname.

Also review whether the provider actually needs an SPF record at a sending subdomain rather than at the root. A root SPF record does not automatically create SPF at send.example.com. DNS names are distinct, and SPF is evaluated at the envelope-sender domain.

Finally, consider SPF lookup count. An SPF policy that has grown through many includes can fail because it causes more than ten DNS lookups during evaluation.

DKIM does not verify

First, confirm the complete queried hostname. If the provider expects:

abc123._domainkey.example.com

then Porkbun should normally show a Host of:

abc123._domainkey

For TXT DKIM, make sure the long public-key value is complete. For CNAME DKIM, make sure you did not paste the provider’s hostname into the Answer/Value field with an accidental typo, internal URL, or copied whitespace.

Some providers issue multiple DKIM records. Add every required selector, not just the first one. Others use a selector that appears to contain a date or random string; that is normal and should not be simplified.

DMARC causes mail to fail

A new DMARC record with p=none should not ask receivers to quarantine or reject failures, though individual mailbox providers may still apply their own spam filtering. If mail disruption begins after moving to quarantine or reject, revert to monitoring while you identify the unaligned or unauthorized sender.

Remember that DMARC evaluates the domain in the visible From header. A tool can have working SPF for its own infrastructure and still fail DMARC when it sends as your domain without aligned SPF or DKIM.

Record Design Choices That Make Future Changes Easier

Email authentication is not a one-time checkbox. Your domain will gain and lose systems over time, teams will add vendors, keys will rotate, and security policies will become stricter.

A maintainable design prevents small DNS changes from becoming production incidents.

Separate transactional and marketing sending when appropriate

Using distinct subdomains can make reputation and operational ownership clearer. For example:

• notify.example.com for product alerts and password resets
• receipts.example.com for invoices and order confirmations
• updates.example.com for newsletters and lifecycle campaigns

Each subdomain can have its own DKIM selectors, SPF policy where needed, and return-path configuration. The root domain can remain focused on employee mail and primary brand communications.

This is not a license to ignore authentication on the root domain. It is a way to minimize accidental SPF bloat, isolate vendor changes, and make DMARC reporting easier to interpret.

Keep a DNS change log

Use Porkbun’s Notes field for a short operational label, but also maintain a team-owned record of:

• The service that owns each DNS record
• The account or workspace where it was created
• The date added or rotated
• The person or team responsible
• Whether removing it would affect sending, receiving, tracking, or website traffic

This context matters months later when someone sees an unfamiliar DKIM selector and assumes it is obsolete.

Treat provider verification as a deployment step

When you add a new email platform, make domain authentication part of the production launch checklist. Verify records before sending customer-facing traffic, test each From address you will use, and confirm actual header results after launch.

That is particularly important for transactional messages. Password resets, receipts, verification links, and security alerts are high-value mail. Their deliverability depends on more than DNS, but correctly configured SPF, DKIM, DMARC, and return-path records provide the authentication foundation those messages need.

Conclusion

To add SPF, DKIM, DMARC, and return-path records in Porkbun, open Domain Management, use the domain’s DNS button or Details followed by the DNS Records edit icon, and add each provider-supplied record in Manage DNS Records.

The critical Porkbun detail is the Host field: for a zone such as example.com, enter the relative label—such as _dmarc, send, selector._domainkey, or pm_bounces—instead of normally pasting the full hostname ending in example.com. Then preserve the provider’s record type and Answer/Value exactly, keep only one SPF record per hostname, start DMARC in monitoring mode, and confirm the resulting messages show aligned authentication passing.

FAQ

What Host should I use for a DMARC record in Porkbun?

Use _dmarc as the Host and TXT as the Type. Porkbun appends your domain, so this publishes the record at _dmarc.example.com for a domain named example.com.

Should I paste the full DKIM hostname into Porkbun?

Usually no. If the provider shows selector._domainkey.example.com and Porkbun manages example.com, enter selector._domainkey in Host. Pasting the entire name can create the wrong doubled hostname.

Can I have more than one SPF record?

Not at the same hostname. Merge all authorized sending mechanisms into one TXT record beginning with v=spf1. You can, however, publish separate SPF records for different subdomains when each hostname has its own mail flow.

Is a custom return-path the same as my visible From address?

No. The visible From address is what recipients see. The return-path is the SMTP envelope sender used for bounces and SPF evaluation. A custom return-path can help SPF align with your visible From domain for DMARC.

How long does Porkbun DNS verification take?

It can be visible within minutes, but caching and provider verification schedules can make it take longer. Check the live DNS name, record type, and exact value before assuming the delay is only propagation.