Map WordPress Email from Submission to Receiver

Separate submission, transport and delivery

What WordPress hands off

WordPress documentation describes wp_mail() as a wrapper that formats and submits a message through a mail library. WordPress does not provide a mail user agent or mail transfer agent by default. In the default setup, the configured PHP mail path depends on a sendmail-compatible local MTA; an installation may instead use a plugin or another configured submission route. The site call alone does not establish which route is active. The WordPress handbook assigns mail-environment configuration to the server administrator and directs managed-host customers to ask their host what is configured. That does not establish that any particular VPS plan includes an MTA, relay, API account or mailbox.

Draw the handoffs

Trace one representative message class as a chain: WordPress event → configured library/plugin → local MTA, SMTP relay or provider API → authenticated sender identity and sending IP → DNS authorization and receiver checks → recipient mailbox, spam handling or rejection → bounce/complaint reporting. At every arrow, write the operator, the evidence that establishes the handoff, and the next operator who receives an error. A relay can accept a submission while the receiver later rejects or filters the message. A successful function return or accepted queue entry therefore cannot be written down as inbox delivery.

Do not merge unlike streams

List core administration alerts, form submissions, transactional messages such as order or password notices, subscribed marketing messages, monitoring alerts, and human mailbox conversations separately. They may share a plugin or transport, but their recipient expectations, volumes, reply handling and receiver rules can differ. Record the recipient class and purpose, not just the plugin name. If one service carries several classes, keep separate rows so a policy for subscribed campaigns is not silently applied to a password reset. To place mail responsibilities beside server, application and support ownership, return to the WordPress owner map; for a security or credential change, see the security page’s credential and change record.

Record sender identity and DNS ownership

Write down identities, not assumptions

For each stream, capture the visible From name and address, Reply-To, envelope sender or return path if known, sending domain, sending service/account, and the person who controls that account. Record the actual sending IP only from evidence supplied by the selected transport. Ask who controls forward and reverse DNS/PTR for that IP and whether the service assigns an address or changes it; leave these fields unknown until documented. For authentication, record the observed SPF source and DKIM signing domain/selector from service documentation or an authorized message record, plus the zone and person who can publish changes. Include the DMARC policy source and review date. Do not invent an SPF include, selector, record value or PTR mapping.

Keep inbound and outbound separate

MX records identify where a domain’s inbound mail is routed. Their presence does not show that WordPress can send outbound mail, that a mailbox exists, or that a sending service is authorized by the domain. A registrar or DNS dashboard visible to an administrator is not proof that it hosts the authoritative zone; identify the actual DNS authority and account owner from current account or provider evidence. Likewise, a From address can differ from the envelope path, and a Reply-To address does not itself authenticate either identity. WordPress’s mail handbook discusses these identity and authorization relationships, but it is not a record of this site’s configuration.

Ask the selected host and relay

Request the current written terms for outbound mail: whether local MTA submission, an external relay or API is expected; any account, volume or abuse restrictions; available sending IP and PTR control; and who handles blocks or reputation escalations. Ask the mailbox provider separately about inbound mail, account administration and retention. WordPress’s handbook mentions port 25 in the context of running an MTA; that passage does not establish a universal block, permission or recommended port for every VPS and relay. Record the selected provider’s dated answer and its exact scope. Until a provider and account are selected, these answers remain unknown.

Preserve receiver and message class

Apply Gmail guidance only to its stated audience

The captured Gmail sender guidance is expressly about personal Gmail accounts ending in @gmail.com or @googlemail.com. It says senders sending more than 5,000 messages per day to Gmail accounts must follow its cited bulk-sender subsection. That is a receiver-specific scope and threshold; it is not a general daily limit for all recipients, all Google Workspace mailboxes or every WordPress installation. For senders over that threshold, the bulk-sender requirements say marketing and subscribed messages must support one-click unsubscribe and include a visible unsubscribe link. Do not expand that message-class requirement to every transactional or administrative notice. When estimating applicability, record how volume was counted and the Gmail recipient share rather than extrapolating from total site mail.

Keep Yahoo’s FAQ distinct

Yahoo’s captured sender FAQ says it does not specify a volume threshold for classifying a bulk sender. Do not substitute Gmail’s more-than-5,000-to-Gmail figure for Yahoo’s undefined “significant volume” wording. The FAQ says one-click unsubscribe is required for promotional or marketing messages, while transactional messages such as order confirmations and password resets are excluded from that requirement. Keep that exclusion attached to those specified examples; classify a message by its actual purpose and consult current Yahoo guidance if its status is uncertain. The FAQ also describes possible spam placement or rejection when requirements are not met; it does not promise delivery when they are.

Date every receiver rule

For each receiver audience, record the primary policy URL, the date you reviewed it, the message classes to which you believe it applies, and who will recheck it before a material campaign or transport change. Guidance can change, and the capture date does not establish the state of a selected host or sending account. Authentication and policy compliance can help satisfy receiver requirements, but neither proves that a message reached an inbox, escaped spam filtering or was accepted by every recipient system. Keep suppression, complaint and bounce responsibilities in the sender’s operating plan instead of treating DNS publication as the end of the delivery path.

Assign ongoing duties

A mailbox is a separate service

Outbound relay or API service, local WordPress submission and inbound mailbox hosting are distinct capabilities. A domain can send through one company and receive through another. Ask who creates and administers mailboxes, pays for them, manages access, handles storage and retention, and responds when a user cannot receive or send. Ask whether WordPress’s From address needs an actual monitored mailbox or only an authorized sender identity; the answer depends on the chosen mail path and business process. Mark any included service, quota, retention period or support promise unknown unless a current offer or contract states it. Do not treat an MX record, hosting control panel or email address as proof of mailbox service.

Name the operator for each failure

Build an owner list for secret custody and rotation, DNS changes, queue retries, rejected messages, bounce and complaint review, suppression requests, reputation escalation, mailbox access, billing and quota notices. Include a named primary and fallback for every duty, with the contract, service documentation or role record that supports the assignment. If the transport provider processes complaints on the sender’s behalf, record what report it provides and who reviews it. If the person who owns DNS cannot see the relay’s signing configuration, assign a handoff and evidence request rather than assuming that one account owner controls both.

Make future validation observable

Before an authorized change, identify what evidence the responsible operator will retain: the approved change request, current record or service setting, post-change observation, relevant queue response, and who interprets any failure. Decide in advance which errors require stopping, whom to contact, and who can restore the prior known value or switch back to the prior transport. A log entry should distinguish “not checked,” “not provided by contract,” “not applicable by owner decision,” and “verified after an authorized action.” No mail send, DNS query or delivery observation was performed for this page.

Use current protocol sources carefully

Treat the RFC status capture as a status notice

The accepted DMARC.org capture reports that RFCs 9989, 9990 and 9991 were published on May 20, 2026, updating DMARC and obsoleting RFC 7489. The full text of the current RFC set is not present in the accepted evidence packet. The packet’s RFC 7489 text is an excerpt and is explicitly retained for provenance, not as the latest normative specification. This article therefore does not turn its old technical details into current configuration instructions. Before publishing standards-level advice, consult the current RFC Editor/IETF primary specifications and verify that any technical explanation follows the relevant current document.

Avoid universal prescriptions

Do not copy a guessed PTR, SPF record, DKIM selector or DMARC policy into a production zone. The correct values and responsibility depend on the selected sender, domain alignment, authoritative DNS and current standards. Do not present one SMTP port as a permanent law for all networks, providers or relays. Ask the network and mail operators what is supported for the actual path, and keep their dated answer with the change record. If the primary source or account-specific evidence is missing, the accurate result is an unresolved field and a request to the owner, not a plausible-looking recipe.

Use a verified mail worksheet

Create one row per stream

Copy this record for each distinct message stream. An empty or “unknown” cell is a useful result: it shows which owner or source must answer before a change or purchase decision.

Work through the decision in order

1. Classify. List every WordPress-created or related stream and who receives it. Separate subscribed marketing from transactional and administrative mail. Record actual volume evidence by receiver; do not project a total to Gmail or Yahoo without recipient data.

2. Obtain service terms.

   Ask the selected host, relay/API provider and mailbox provider for the exact product, sender setup, limits, PTR/IP responsibility, abuse handling, mailbox features, fees and billing period. Save the current dated source. Keep missing scope unknown instead of marking it included or free.

3. Confirm DNS authority.

   The authorized DNS operator identifies the authoritative zone and current record source before any proposed edit. The sender operator supplies the values it expects and explains signing responsibility. The operator records approval, prior state, intended change, validation evidence and reversal authority. This worksheet supplies no record values and authorizes no change.

4. Set the verification plan.

   The mail owner chooses an appropriately authorized future validation method and receiver scope, then records the evidence and date only after it happens. Name who will inspect queue errors, bounce or complaint feedback, and mailbox behavior. The plan is not a claim that a test was run.

5. Stop on missing control.

   Pause if sender identity is disputed, the zone authority or secret custodian is unknown, the provider terms are unavailable, no accountable operator can observe failures, or no owner can reverse a change. Resolve those gaps before changing DNS, credentials or transport. For the broader clocks that can affect mail during a move, consult the WordPress lifecycle page; selected service and optional labor costs belong in the matched-period cost worksheet.

When this record is complete, the result should say who submits, transports, authenticates and receives each stream’s errors, with source and date beside each claim. If the exact service, receiver rule or account owner remains unknown, return that gap to the WordPress responsibility map. This creates a useful handoff without claiming that mail is configured or deliverable.

Sources and review date

Primary references captured for this draft on November 6, 2026. Recheck living receiver guidance and standards before publication and again before relying on a rule for a real stream. The capture date is not a claim about any host, domain or sender account.

• WordPress Developer Resources: Mail — submission, MTA responsibility, sender fields and mail setup discussion.
• Google: Email sender guidelines — personal Gmail sender scope, bulk subsection and message-class requirements.
• Yahoo Sender Hub: FAQs — bulk threshold wording and marketing versus transactional unsubscribe scope.
• DMARC.org: protocol status — captured notice of RFC 9989/9990/9991 status. Consult the RFC Editor for current primary specifications; their full text was not in the accepted evidence reviewed for this draft.

Page status: Draft — requires independent review and current-source recheck. No DNS, email, mailbox, provider account or server test was performed.