Email consent is the permission—or, in limited contexts, another legally valid basis—you rely on before sending someone email. For developers, the useful question is not simply “do we have an email address?” but “what message may we send to this person, why, where did that permission come from, and can we prove it?”

That distinction matters because a technically successful send is not evidence of permission. An SMTP server can return 250 2.0.0, an HTTP email API can accept your request with a 202 Accepted, and a mailbox can exist, yet the recipient may never have agreed to receive marketing from you. Consent is a product, data-modeling, compliance, and deliverability concern—not an API response code.

This guide is vendor-neutral and focuses on practical implementation. It is not legal advice. Email rules differ by recipient location, message category, sender identity, and business relationship, so use qualified legal advice for your situation—especially for cross-border programs, regulated industries, purchased data, and affiliate marketing.

The short definition: what counts as email consent?

In the strongest and simplest form, email consent means a person took a clear affirmative action to agree that a named organization may send them a defined category of email at that address. A checked-by-default box, a vague privacy-policy reference, or a silent failure to untick a box is usually much weaker than an intentional opt-in.

A durable consent record answers five questions:

Who consented? The email address and, where applicable, the identifiable person or account associated with it.
Who may send? Your company, brand, and any clearly identified sender acting on its behalf.
What did they agree to receive? For example, a weekly product newsletter, event announcements, or promotional offers—not an unlimited category called “communications.”
How and when did they agree? The form, checkbox state, API event, timestamp, source page, language shown, and evidence of confirmation.
Can they withdraw it easily? Every relevant marketing send must respect a current unsubscribe or suppression state.

The practical standard is: if you had to explain the send to the recipient, a mailbox provider, an auditor, or a regulator six months later, could you show why that specific email was expected?

Consent is not the same as contact information

A work email found on a public website is contact information. A conference attendee list is contact information. A customer’s checkout email is contact information. An address entered by a colleague is contact information.

None automatically establishes permission for every type of email. A person may reasonably expect a receipt after a purchase, a password-reset link after requesting one, or a security notice about their account. They may not expect a recurring newsletter, partner promotions, webinar invitations, or sales sequences merely because you have their address.

This is also why address validation is valuable but limited. A verifier can help identify malformed, risky, disposable, or undeliverable addresses; it cannot prove that the human behind a deliverable mailbox wants marketing. Use an email verification tool to improve list hygiene, but do not treat a “valid” result as a consent signal.

Start by classifying the message, not the recipient

The same person can be eligible for one message type and ineligible for another. Build sending decisions around a message classification field rather than a single, global subscribed: true boolean.

Transactional or relationship messages

A transactional message is directly connected to an action, account, transaction, security event, or service relationship. Typical examples include:

Password resets and one-time passcodes.
Email-address verification links.
Purchase receipts, invoices, shipping updates, and refunds.
Service outages, security alerts, and material changes to an account.
A requested export, report, or support-ticket update.
Renewal or billing notices necessary to administer an existing subscription.

In the United States, the CAN-SPAM Act distinguishes transactional or relationship messages from commercial messages. That does not mean transactional mail is a loophole for promotional content. The primary purpose and actual content matter. A receipt with a modest, related product recommendation may be treated differently from a “receipt” dominated by an advertisement, a sales banner, and multiple promotional calls to action.

Operationally, transactional email is usually based on the user’s action or an existing service relationship rather than newsletter consent. But you should still send only what is necessary, use an accurate sender identity, minimize promotional material, and offer the user account-level controls where appropriate. A security alert should not stop because someone unsubscribed from marketing; a marketing campaign must stop when they do.

Marketing and promotional messages

Marketing email promotes products, services, upgrades, events, content, or brand engagement. Common examples include product newsletters, discount announcements, abandoned-cart programs, upsell messages, sales outreach, partner offers, and webinar invitations.

For this category, explicit opt-in is generally the most defensible operating rule. Some jurisdictions and contexts permit alternatives such as a carefully limited existing-customer exception, sometimes called a soft opt-in. Those exceptions are narrow, context-specific, and easy to overextend. Do not turn “they bought something once” into a permanent license for unrelated campaigns.

Mixed messages are the dangerous middle

Many operational messages contain both service and marketing content. Examples include a billing notice that advertises an annual upgrade, an account-confirmation email with a large referral promotion, or a shipment update that primarily drives another purchase.

Treat a message as marketing when promotional content becomes a material purpose rather than a minor, clearly secondary component. If a campaign needs marketing consent to be safe, do not relabel it as transactional to bypass suppression. Mailbox providers and recipients judge the real experience, not the internal event name.

A useful engineering rule is to require a message_type at send time, such as transactional, security, service, or marketing. Make the marketing path enforce marketing eligibility by default. Do not let callers choose transactional freely without review for templates that contain promotional copy.

What affirmative consent looks like in practice

The most reliable email consent is specific, informed, freely given, and recorded. The exact legal terminology varies, but the implementation principles travel well.

Clear opt-in language

A good form separates necessary account actions from optional marketing. For example:

“Yes, email me product updates, practical guides, and occasional offers from Example Co. I can unsubscribe at any time.”

The checkbox should be unchecked by default when consent is required. The statement should name the sender and describe the category and channel. If separate brands will send email, name them. If you plan to share an address with third parties for their own marketing, say so plainly rather than hiding it behind “trusted partners.”

Avoid language such as “By continuing, you agree to receive communications,” especially when the person must continue to create an account or complete a purchase. It does not tell the person what is optional, what is necessary, or what they will receive.

Double opt-in

Double opt-in adds a confirmation step after someone submits an email address. Your application sends a confirmation link; only a successful click changes the subscription to active.

Double opt-in is not universally mandatory, but it offers meaningful advantages:

It reduces typo addresses and malicious signups.
It produces stronger evidence that the mailbox owner participated.
It prevents a third party from subscribing someone else without their knowledge.
It creates a clean event trail useful in disputes.
It tends to improve engagement and reduce complaint risk.

A robust flow has at least these states: pending_confirmation, subscribed, unsubscribed, and suppressed. Do not send recurring marketing while the address is pending. Expire confirmation tokens, make them single-use, and avoid confirming a subscription merely when a confirmation email is opened; an open can be generated by privacy proxies, scanners, or mailbox software.

Consent obtained offline or through sales

Consent can be collected through a paper form, a phone interaction, a point-of-sale workflow, a sales representative, or an event registration. The principle is the same: create evidence that identifies what the person agreed to.

For an event, preserve the registration language and checkbox state. A badge scan alone often proves attendance or interest in the event, not permission for a long-term marketing program. For verbal consent, record the date, representative, context, script version, and any call-recording reference allowed by applicable law. For an import from a CRM, retain the original source and consent metadata rather than copying only the address and an optimistic marketing=true field.

What does not count as reliable email consent

Teams often inherit data that feels usable because it is old, large, or associated with a legitimate business interaction. That is exactly where poor consent practices begin.

Purchased, rented, scraped, or appended lists

A list broker’s assurance that a list is “opted in” does not necessarily mean recipients consented to hear from your brand, from your sending domain, or about your specific offer. Consent that is too generic, stale, hidden in a third-party privacy notice, or not transferable to your organization is weak evidence.

Scraped email addresses are not consent. Email addresses collected from social profiles, websites, directories, source-code commits, or data-enrichment tools are not consent. Likewise, appending email addresses to customer records can help identify a contact, but it does not establish marketing permission.

These practices also create a deliverability problem. Recipients are more likely to ignore, mark as spam, or report unfamiliar mail. Complaint signals, low engagement, spam traps, and invalid addresses can damage domain and IP reputation even if your sending infrastructure is fully authenticated.

Prechecked boxes and bundled permission

A checkbox that is already checked invites ambiguity. A single checkbox that combines product terms, privacy processing, SMS, email marketing, partner sharing, and profiling is not meaningful granularity. Consent should not be buried in terms that a user must accept to buy a product or open an account when the marketing itself is optional.

Separate the essential service agreement from optional marketing. Store each preference independently. “Agreed to terms” is not a substitute for “opted into newsletter.”

Old or unverifiable consent

Age alone does not automatically invalidate every permission record, but stale consent is risky when you cannot show what the person saw, the sender identity has changed, the purpose has expanded, or the recipient has not engaged for a long time.

If you acquired a company, renamed a brand, changed your product category, or moved data between systems, review whether the original expectation still fits. A repermission campaign can be appropriate, but it must itself be sent only where you have a lawful basis to send it. In some cases, the correct solution is to stop marketing to that segment rather than emailing a list of people whose status you cannot substantiate.

A bounce-free send is not approval

A 250 response from the next SMTP hop means that server accepted the message for handling. It does not mean the recipient saw it, read it, liked it, or consented to it. Similarly:

202 Accepted from an HTTP email endpoint generally means the provider accepted the request for processing, not that the email reached the inbox.
550 5.1.1 commonly indicates an invalid or unavailable mailbox.
421 4.7.0 is a temporary SMTP response often associated with policy, rate, or reputation controls, depending on the receiver’s text.
A spam complaint is a user feedback signal, not a dependable legal adjudication—but it is a strong operational reason to stop or reduce sending.

Keep transport events, deliverability events, and consent events in separate fields. Conflating them leads to false assumptions such as “delivered equals subscribed” or “hard bounce means unsubscribe.”

Consent requirements vary by jurisdiction

A global application should avoid treating one country’s minimum rule as a universal best practice. The recipient’s location, the message’s audience, and the sender’s establishment can all matter. The following is a practical overview, not a complete legal analysis.

United States: commercial email and opt-out

The U.S. CAN-SPAM framework focuses heavily on commercial email requirements: accurate header information, non-deceptive subject lines, identification and address requirements, a functioning opt-out mechanism, and timely honoring of opt-outs. It is not generally an opt-in-only rule for commercial email in the way some other regimes are.

That baseline should not be mistaken for a deliverability strategy. Sending unsolicited commercial email may be legally possible in a narrower sense while still being unwelcome, complaint-prone, and contrary to mailbox-provider expectations. The FTC says commercial opt-outs must be honored within 10 business days, while modern mailbox-provider guidance can demand substantially faster operational handling.

United Kingdom and European contexts: consent and limited exceptions

For marketing emails to individuals in the UK, PECR generally requires consent unless a limited soft opt-in applies. The soft opt-in is tied to collecting contact details in the context of a sale or negotiations for a sale of your own similar products or services, providing an opt-out at collection, and providing an opt-out in each subsequent message.

In European data-protection contexts, you may also need a lawful basis for processing the underlying personal data, transparency notices, and systems that respect objections and withdrawals. Do not assume business-to-business email is universally exempt: the rules can vary by country, recipient type, and the personal nature of the address.

Canada: commercial electronic messages

Canada’s Anti-Spam Legislation, commonly called CASL, requires consent, sender identification, and an unsubscribe mechanism for commercial electronic messages, subject to defined exceptions and forms of implied consent. It is notable for placing the burden on senders to demonstrate consent.

For product teams, the conservative takeaway is straightforward: preserve proof; distinguish express consent from time-limited or relationship-based implied consent; and do not let a generic CRM label erase expiry logic. If your program reaches Canadian recipients, get legal advice before relying on implied consent at scale.

Build for the strictest reasonable standard

When you cannot confidently resolve geography at send time, a permission-based model is safer than a patchwork of minimum rules. Explicit opt-in, purpose-specific categories, clear identity, easy withdrawal, and a strong audit trail improve both compliance posture and deliverability across regions.

Design a consent data model developers can trust

A marketing preference needs more than one Boolean. A durable system treats consent as an append-only set of events plus a current eligibility projection.

Suggested consent event schema

The following JSON is illustrative; adapt field names to your system:

{
  "event_id": "cns_01JQ8Y...",
  "email": "alex@example.net",
  "subject_id": "usr_12345",
  "event_type": "marketing_opt_in",
  "channel": "email",
  "purpose": "product_newsletter",
  "status": "granted",
  "occurred_at": "2026-08-12T14:03:22Z",
  "source": "web_signup",
  "form_version": "newsletter-v4",
  "consent_text": "Yes, email me product updates...",
  "checkbox_checked": true,
  "ip_address": "198.51.100.42",
  "user_agent": "Mozilla/5.0 ...",
  "confirmation": {
    "method": "double_opt_in",
    "sent_at": "2026-08-12T14:03:24Z",
    "confirmed_at": "2026-08-12T14:07:09Z"
  }
}

Use UTC timestamps and immutable event IDs. Store the exact or versioned consent text shown to the user, not merely the current copy on your website. If privacy considerations make retaining a full IP address inappropriate for your organization, document your retention and minimization approach; do not silently discard all evidence needed to establish how consent was collected.

Maintain a separate current-state projection

At send time, you need fast decisions. Derive a current preference record from the event ledger, for example:

{
  "email": "alex@example.net",
  "marketing_eligible": true,
  "purposes": ["product_newsletter"],
  "unsubscribed_at": null,
  "global_suppressed": false,
  "last_verified_at": "2026-08-12T14:07:09Z"
}

Your send worker should check the current state immediately before queuing a marketing message. If a recipient unsubscribes between campaign selection and delivery, suppression should win. For high-volume systems, this means synchronizing suppression changes quickly across queues, campaign services, CRM exports, and any SMTP or REST sending integration.

Keep purpose and brand boundaries

A recipient may agree to a technical newsletter but not sales offers. They may agree to emails from one product brand but not a parent company’s other brands. Model these boundaries directly.

Useful fields include brand, purpose, channel, jurisdiction_basis, expires_at, and evidence_reference. Avoid a universal subscription flag that makes future segmentation impossible. Granular preferences reduce accidental overmailing and give recipients meaningful control without forcing them to choose between “everything” and “nothing.”

For implementation examples involving REST sending or an SMTP relay, consult the provider’s email API reference and setup guides, but keep consent checks in your application or audience layer rather than assuming the transport service can infer permission from message content.

Unsubscribes, suppressions, and preference centers

Consent is reversible. A correctly collected opt-in does not override a later unsubscribe, spam complaint, privacy objection, or account-level marketing preference.

An unsubscribe is an operational event

When a recipient opts out, process it as a high-priority state change—not as a nightly batch job. For marketing messages, stop future sends promptly across all systems that can send on your behalf.

At minimum, record:

The email address or recipient identifier.
The time and source of the request.
Whether it was a list-level, category-level, or global marketing opt-out.
The brand and purpose affected.
The message or campaign that generated the request, when available.
The downstream systems updated and any processing errors.

Keep a suppression record even if the person requests account deletion, subject to applicable privacy rules and your legal advice. Otherwise, a future import could re-add the address and resume unwanted marketing. The suppression record should contain the minimum data necessary to prevent recontact and should be protected accordingly.

Footer links and one-click headers solve different problems

Marketing email should include a clear visible unsubscribe path. That path should not require login, a survey, a password, or an account search before it takes effect. A preference center can offer categories, but it should also provide an obvious option to stop all marketing mail.

For bulk and subscription mail, support standard list-unsubscribe headers in addition to a footer link. A typical header set can look like this:

List-Unsubscribe: <https://example.com/unsubscribe/u/abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post header is part of the one-click mechanism described by RFC 8058. The HTTPS endpoint must perform the unsubscribe from the one-click POST without asking the recipient to log in or take another confirmation action. Use an opaque, signed, expiring token that identifies the subscription safely; do not put a raw email address or reusable database ID in the URL.

Google’s current subscription guidance says to process and honor unsubscribes within 48 hours. Even if a law provides a longer outer deadline in a particular jurisdiction, engineering for near-real-time handling is the safer user experience and reduces complaint risk.

Do not unsubscribe essential transactional mail by accident

A marketing opt-out should normally stop promotional mail, not password resets, receipts, legal notices, fraud alerts, or critical service alerts. That is why message taxonomy and send-time policy checks are essential.

At the same time, do not exploit this separation. If an “account update” is sent weekly and mostly markets features, users and mailbox providers will see it as marketing regardless of the template name. Keep the transactional stream genuinely event-driven and necessary.

Authentication, DNS, and consent work together—but do different jobs

Authentication does not create email consent. Consent does not repair unauthenticated mail. You need both: permission makes messages expected, while authentication lets receiving systems verify that the message is genuinely associated with your domain.

SPF record example

SPF is published as a DNS TXT record and authorizes sending infrastructure for the envelope sender domain. A generic example is:

example.com. IN TXT "v=spf1 include:spf.your-email-provider.example -all"

Use the exact include: value supplied by your email provider; do not invent it from the provider’s name. Publish only one SPF TXT record for a domain, merge authorized sources into that record, and remember that SPF has a DNS lookup limit defined by its specification. The final -all indicates a hard fail for mechanisms not matched; the correct policy depends on your authorized senders and rollout plan.

DKIM record example

DKIM signs messages with a private key and publishes the corresponding public key at a selector-specific DNS name. A simplified record format is:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The selector and public key are generated by your provider or your own signing infrastructure. Do not copy the placeholder key. Confirm that the visible From: domain is aligned with a passing DKIM signing domain when building toward DMARC enforcement.

DMARC record example

DMARC publishes policy and reporting preferences under _dmarc:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Start with monitoring (p=none) while reviewing reports, then consider stronger policies such as p=quarantine or p=reject once all legitimate sources are aligned. Strict alignment tags, adkim=s and aspf=s, can be appropriate but require careful testing with every application, help desk, billing platform, and email service that sends as your domain.

Tools such as MXToolbox can inspect DNS records and mail-tester.com can help you review a test message’s authentication and content signals. They are diagnostic tools, not compliance certificates. A perfect technical score does not prove consent, and a well-consented campaign can still fail delivery if authentication, reputation, or list quality is poor.

Make consent enforcement part of the sending architecture

A transport provider can accept mail through a REST API or SMTP relay, but it cannot reliably determine whether your business had permission to send a particular campaign. That decision belongs in the systems that own audience data and message intent.

A practical send-time decision flow

Before submitting a marketing message, evaluate the following in order:

Classify the message. Is it transactional, security, service, or marketing?
Resolve the recipient. Normalize the address and load its current preference and suppression status.
Check scope. Does the recipient have active permission for this brand, channel, and purpose?
Check exclusions. Has the recipient globally unsubscribed, complained, hard bounced, or been manually suppressed?
Check timing and eligibility. Has implied consent expired? Is frequency within your product’s stated expectation?
Render compliance elements. Add the correct sender identity, postal/contact details where required, visible unsubscribe link, and list-unsubscribe headers.
Send and log. Record the template version, campaign, consent evidence reference, provider message ID, and final policy decision.

For transactional mail, use a narrower check: validate the triggering event, confirm the recipient relationship, apply safety and abuse controls, and avoid marketing-only templates. Keep the audit trail because it helps explain unexpected sends and supports incident response.

Example policy pseudocode

if message.type == "marketing":
    require recipient.marketing_eligible == true
    require recipient.global_suppressed == false
    require recipient.allowed_purposes contains message.purpose
    require consent_not_expired(recipient, message)
    add_unsubscribe_headers(message)
    add_visible_unsubscribe_link(message)

if message.type in ["transactional", "security"]:
    require valid_triggering_event(message)
    require recipient.global_delivery_suppressed == false
    forbid_promotional_template_content(message)

The exact rules should be tailored to your legal advice and product behavior. The important design choice is that an application cannot bypass consent policy merely by changing a template label or calling a lower-level SMTP function directly.

Deliverability signals are feedback on expectation

Consent and deliverability are closely connected because recipients who expected your email are more likely to engage and less likely to complain. But engagement is not consent, and lack of engagement is not necessarily an opt-out.

Watch the signals that reveal bad permission practices

Monitor performance by source, signup form version, geography, sender domain, and campaign type. Sudden problems often trace back to one acquisition path rather than the entire program.

Pay particular attention to:

Spam complaint rate and complaint source.
Hard bounces and invalid-recipient responses.
Unsubscribe rate, especially immediately after a first campaign.
Low engagement from a newly imported segment.
Authentication failures and DMARC alignment results.
Deferrals or blocks with 4xx or 5xx SMTP status patterns.
Support tickets asking why the person received the email.

Do not react by hiding unsubscribe links or making them difficult to use. That may reduce recorded unsubscribes while increasing spam complaints, which is worse for both recipients and sender reputation.

Re-engagement is not a cure for unknown provenance

A carefully consented but inactive subscriber might receive a limited re-engagement campaign, subject to your policy and applicable law. An address with no verifiable source should not be “cleaned” through a re-engagement blast. If you cannot explain why the person should recognize your sender, do not send marketing merely to test whether they complain.

Mailbox providers increasingly expect bulk senders to avoid unwanted or unsolicited mail, authenticate sending domains, and provide easy unsubscribe mechanisms. A permission-first program is therefore not only a compliance practice; it is a reputation-management strategy.

Common consent scenarios and the right default

“A user created an account”

You can normally send account verification, password reset, security, and necessary service emails. Do not assume account creation means the user opted into newsletters. Use a separate optional marketing choice.

“A customer made a purchase”

Send order confirmation, receipt, shipping, and support communications needed to complete the transaction. Marketing follow-up may be possible in some jurisdictions under a limited existing-customer rule, but explicit consent remains the cleaner cross-border approach—especially for unrelated products or extended campaign sequences.

“Someone downloaded a white paper”

They consented to receive the requested asset. That alone does not necessarily mean they consented to a recurring sales or newsletter sequence. Put a separate, clear email-marketing opt-in on the form if you want one.

“A sales representative met them at a conference”

A follow-up that directly relates to the conversation may be reasonable in some contexts, but a badge scan or business card is weak evidence for broad, recurring marketing. Log the interaction, make the sender identifiable, and obtain an explicit subscription for ongoing campaigns.

“They gave consent to our old brand”

Review whether the new sending identity, product, and purpose remain within the original expectation. An acquisition, brand migration, or major product pivot may justify fresh permission rather than assuming consent transferred intact.

“They clicked an unsubscribe link”

Do not send another marketing email asking them to confirm their choice. Apply the suppression immediately, show a confirmation page, and retain a minimal suppression record. You may continue essential transactional mail where appropriate.

A practical consent checklist

Before launching a new email source or campaign, verify all of the following:

The form uses clear, optional, unchecked marketing consent where required or appropriate.
Consent language names the sender and describes the message category.
The system records timestamp, source, form version, checkbox state, and proof of confirmation where used.
Marketing, transactional, security, and service messages have distinct classifications.
Marketing sends perform a real-time or near-real-time preference and suppression check.
Unsubscribe requests update every campaign and sending system promptly.
Footer unsubscribe links and list-unsubscribe headers are tested.
Imported lists retain original consent provenance rather than a blanket “subscribed” label.
SPF, DKIM, and DMARC are configured for the sending domain and tested after changes.
You review complaints, bounces, and unsubscribes by acquisition source.
You have a documented retention policy for consent evidence and suppression data.
Legal, product, marketing, and engineering agree on definitions of “transactional” and “marketing.”

The final item matters more than it seems. Many consent failures happen when one team calls a message “service communication” while another team designs it as a campaign. Establish template governance and require review when a transactional template gains promotional content.

Conclusion

What counts as email consent is not “the email address is in our database” or “the message was delivered.” Strong email consent is an affirmative, specific, recorded permission that matches the sender, purpose, and current message category. Where you rely on a relationship-based or jurisdiction-specific exception instead, document why it applies and keep that logic narrow.

Build consent into your data model, not into a spreadsheet note. Separate marketing from transactional mail, record proof at collection time, process unsubscribes immediately, authenticate your sending domain, and treat recipient expectations as a core engineering requirement. That approach protects users, reduces complaints, and gives every email provider—whether you send through SMTP or an API—better conditions to deliver the messages people actually want.

FAQ

Is an email address on a business card consent to send marketing?

Usually, no—not by itself. It may support a contextual, relevant follow-up after a real interaction, but it is weak evidence for an ongoing marketing subscription. Ask for a clear opt-in for recurring campaigns.

Does double opt-in count as better email consent?

Yes. Double opt-in is strong practical evidence because the mailbox owner confirms the subscription through a link or similar action. It also reduces typos, fake signups, and complaints, although it is not required in every jurisdiction.

Can I send transactional email after someone unsubscribes?

Generally, a marketing unsubscribe should stop marketing, not necessary messages such as password resets, receipts, security alerts, or requested support updates. Keep transactional content genuinely necessary and avoid using it as a promotional channel.

Is a valid SMTP response proof of consent?

No. A response such as 250 2.0.0 indicates that a mail server accepted the message for processing. It says nothing about whether the recipient expected, wanted, or legally consented to receive marketing.

Do SPF, DKIM, and DMARC create email consent?

No. They authenticate your mail and help receiving systems assess whether it is legitimately associated with your domain. Consent concerns recipient permission; authentication concerns sender identity and message handling. You need both.

What Counts as Email Consent? A Developer’s Practical Guide