برای اینکه احراز هویت DKIM "تراز شده" در نظر گرفته شود، دامنه سازمانی حداقل یک دامنه امضای تایید شده توسط DKIM باید با دامنه سازمانی آدرس ایمیل در هدر From باشد. این معادل تراز شناسه DKIM آرام است که در مشخصات DMARC، RFC7489 بخش 3.1.1 تعریف شده است.
دامنه سازمانی در RFC7489 بخش 3.2 تعریف شده است و به عنوان بخش "eTLD+1" دامنه نیز نامیده می شود. به عنوان مثال، دامنه foo.bar.example.com دارای example.com به عنوان دامنه سازمانی خود است.
دامنه امضای تایید شده با DKIM به مقدار تگ d= امضای DKIM اشاره دارد.
برای مثال، اگر یک امضای معتبر DKIM با موفقیت با d=foo.example.com تأیید شود، bar@foo.example.com ، foo@example.com و foo@bar.example.com همگی در صورت وجود در تراز در نظر گرفته می شوند. From header در حالی که user@gmail.com این کار را نمی کند، زیرا gmail.com با example.com مطابقت ندارد.
رمزگذاری TLS
برای اطمینان از اینکه محتویات یک ایمیل AMP در حین انتقال رمزگذاری شده است، باید ایمیل های حاوی AMP را با TLS رمزگذاری کنید .
تمام درخواست‌های XMLHttp (XHR) که از یک ایمیل AMP سرچشمه می‌گیرند، پروکسی هستند. این کار برای محافظت از حریم خصوصی کاربر انجام می شود.
سرصفحه های CORS
تمام نقاط پایانی سرور مورد استفاده توسط amp-list و amp-form باید CORS را در AMP برای ایمیل پیاده سازی کنند و هدر HTTP AMP-Email-Allow-Sender به درستی تنظیم کنند.
محدودیت ها
در زیر محدودیت های URL اضافی توضیح داده شده است.
تغییر مسیرها
URL های XHR نباید از تغییر مسیر HTTP استفاده کنند. درخواست‌هایی که کد وضعیت را از کلاس تغییر مسیر (محدوده 3XX ) باز می‌گردانند مانند 302 Found یا 308 Permanent Redirect با شکست مواجه می‌شوند و در نتیجه یک پیام هشدار کنسول مرورگر ایجاد می‌شود.
تاریخ آخرین بهروزرسانی 2025-03-25 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-03-25 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Security requirements\n\nTo ensure user safety and privacy, dynamic emails are subject to additional\nsecurity requirements and restrictions.\n| **Warning:** Failure to comply with these results in parts of the dynamic email not rendering correctly or Gmail falling back to HTML and not rendering the AMP part of the email at all.\n\nSender Authentication\n---------------------\n\nTo ensure the sender of an AMP email is legitimate, emails containing AMP are\nsubject to the following checks:\n\n- The email must pass [Domain Keys Identified Mail (DKIM) authentication](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail).\n- The DKIM-authenticated signing domain must be aligned with the domain of the email in the `From` field. See [DKIM Alignment](#dkim_alignment) below.\n- The email must pass [Sender Policy Framework (SPF) authentication](https://en.wikipedia.org/wiki/Sender_Policy_Framework).\n\nIn addition, it's recommended that email senders use a [Domain-based Message Authentication, Reporting and Conformance (DMARC) policy](https://en.wikipedia.org/wiki/DMARC)\nwith disposition set to either `quarantine` or `reject`. This may be enforced in the\nfuture.\n\nDKIM, SPF and DMARC each appear as separate lines within the \"Show Original\"\nmenu option in Gmail Web. See\n[Check if your Gmail message is authenticated](https://support.google.com/mail/answer/180707)\nfor more information.\n\n### DKIM Alignment\n\nIn order for DKIM authentication to be considered \"aligned\", the *Organizational Domain*\nof at least one *DKIM-authenticated signing domain* must be the same as the\n*Organizational Domain* of the email address in the `From` header. This is equivalent to the\nrelaxed DKIM Identifier Alignment as defined in the DMARC specification,\n[RFC7489 Section 3.1.1](https://tools.ietf.org/html/rfc7489#section-3.1.1).\n\n*Organizational Domain* is defined in [RFC7489 Section 3.2](https://tools.ietf.org/html/rfc7489#section-3.2)\nand is also referred to as the \"eTLD+1\" part of the domain. For example, the domain `foo.bar.example.com`\nhas `example.com` as its *Organizational Domain*.\n\n*DKIM-authenticated signing domain* refers to the value of the `d=` tag of the\nDKIM signature.\n\nFor example, if a validated DKIM signature successfully verifies with\n`d=foo.example.com`, then `bar@foo.example.com`, `foo@example.com` and\n`foo@bar.example.com` would all be considered aligned if present in the `From`\nheader while `user@gmail.com` would not, as `gmail.com` doesn't match\n`example.com`.\n\nTLS Encryption\n--------------\n\nTo ensure the contents of an AMP email are encrypted in transit, you must\n[TLS Encrypt](https://en.wikipedia.org/wiki/Transport_Layer_Security) emails\ncontaining AMP.\n\nAn icon in Gmail indicates whether an email was sent with TLS Encryption. See\n[Check if a message you received is encrypted](https://support.google.com/mail/answer/6330403)\nfor more information.\n\nHTTP proxy\n----------\n\nAll XMLHttpRequests (XHRs) that originate from an AMP email are proxied. This is\ndone to protect the user's privacy.\n| **Note:** As a result of proxying, XHR requests don't contain cookies. For information on how to provide authentication, see [Authenticating requests in AMP for email](/workspace/gmail/ampemail/authenticating-requests).\n\n### CORS Headers\n\nAll server endpoints used by `amp-list` and `amp-form` must implement\n[CORS in AMP for Email](https://amp.dev/documentation/guides-and-tutorials/learn/cors-in-email/?format=email)\nand correctly set the `AMP-Email-Allow-Sender` HTTP header.\n\n### Restrictions\n\nThe following describes additional URL restrictions.\n\n#### Redirects\n\nXHR URLs mustn't use HTTP redirection. Requests that return a status code from\nthe redirection class (`3XX` range) such as `302 Found` or `308 Permanent Redirect`\nfail, resulting in a browser console warning message."]]
